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ABSTRACT 


The  Global  Broadcast  Service  utilizes  commercial  direct  broadcast  satellite  technology 
tailored  specifically  for  military  application.  With  this  service,  the  military  directly 
addresses  oversubscribed  communication  paths  and  introduces  a  quantum  leap  in 
information  dissemination.  However,  the  potential  for  information  overload  comes  with 
the  ability  of  this  service  to  readily  deliver  multi-megabit  per  second  data.  Therefore,  to 
make  the  Global  Broadcast  Service  a  value-added  addition  to  command  and  control,  an 
information  management  process  must  be  developed  concurrently. 

This  project  builds  a  Global  Broadcast  Service  model  (using  Extend™)  to  provide  a 
tool  to  analyze  information  dissemination  management.  Recent  technologies  such  as 
asymmetric  networking  and  automated  radio  frequency  management  are  integrated  into 
the  model.  In  this  thesis,  asymmetric  networking  is  equated  to  Global  Broadcast  Service 
“reach  back,”  and  automated  radio  frequency  management  is  equated  to  the  functionality 
of  the  “Automated  Digital  Network  System.”  Using  a  simulation,  an  initial  analysis  of 
various  reach  back  chaimels  is  provided.  The  resulting  model  and  analysis  serve  as  a 
foimdation  for  future  process  development  for  Global  Broadcast  Service  Information 
Dissemination  Management. 


V 


vi 


TABLE  OF  CONTENTS 


L  INTRODUCTION . 1 

A.  PURPOSE  OF  RESEARCH . 1 

B.  SCOPE  OF  THESIS . 2 

C  THESIS  ORGANIZATION . 4 

IL  BACKGROUND . 7 

A.  GBS  OVERVIEW . 7 

7.  History . . . 7 

2.  Three  Phases  of  GBS . : . 12 

3.  GBS  Phase  II  System  Architecture . 15 

B.  GBS  REACH  BACK . . . ! . 16 

7.  Description . 16 

2.  Four  Reach  Back  Connectivity  Modes . .18 

3.  Reach  Back  Experiments . 19 

4.  Commercial  Analogies . 23 

C.  INFORMATION  DISSEMINATION  MANAGEMENT  (IDM) . 25 

7.  Information  Management  (IM) . 25 

2.  Information  Dissemination  Management  (IDM) . 26 

3.  IM  and  IDM  Strategy  with  GBS . 26 

4.  Role  of  Theater  Information  Management  (TIM) . 27 

III.  GBS  CONCEPT  OF  OPERATIONS  (CONOPS) . 29 

A.  Mission  Needs  Statement  (MNS) . 29 

B.  GBS  ORD . 30 

C.  GBS  JOINT  CONOPS . 34 

IV.  GBS  MODEL  DESIGN  AND  ANALYSIS . 39 

A.  INTRODUCTION  TO  EXTEND . 39 

7.  What  is  Extend?.. . 39 

2.  Limitations  of  Extend . 40 

B.  METHODOLOGY . 41 

7.  Modeling  Tool  Selection . 41 

'  2.  Network  Characterization  and  Model  CONOPS  Description . 43 

3.  Logical  Model  Development . 50 

4.  Simulation  and  Data  Collection . 91 

5.  Data  Analysis . 96 

V.  CONCLUSIONS . ..99 

A.  SUMMARY . 99 

7.  General  Advantages  of  Reach  Back  for  User  Pull  Products . 101 

2.  General  Disadvantages  of  Reach  Back  for  User  Pull  Products . 104 

3.  Reach  Back  Channel  Findings . 106 

B.  RECOMMENDATIONS  AND  AREAS  FOR  FURTHER  STUDY . 1 1 1 

7.  Recommendations . 112 

2.  Areas  for  Future  Study . 114 


vii 


APPENDIX  A.  GBS  PHASE  II  CONFIGURATIONS . 119 

APPENDIX  B.  REACH  BACK  CONNECTIVITY  MODES . 121 

APPENDIX  C.  IDM  SERVICES . 123 

APPENDIX  D.  CINC  GBS  CONOPS  (DRAFTS) . 125 

APPENDIX  E.  GROUND  RECEIVE  SUITE  FIELDING  AND  CONFIGURATIONS . 135 

APPENDIX  F.  EXTEND  BLOCK  DEFINITIONS . 137 

APPENDIX  G.  MODEL  BANDWIDTH  AND  FUTURE  REQUIREMENTS . 155 

APPENDIX  H.  SATCOM  PRIORITY  TABLE . 161 

APPENDIX  I.  EXTEND  DEFAULT  NOTEBOOK  SETTINGS . 163 

APPENDIX  J.  GBS  PRODUCTS . 165 

APPENDIX  K.  GBS  MODEL  DATA  TABLES . 169 

APPENDIX  L.  GLOSSARY . 181 

APPENDIX  M.  ACRONYMS . 185 

LIST  OF  REFERENCES . 191 

INITIAL  DISTRIBUTION  LIST . 195 


viii 


LIST  OF  FIGURES  AND  TABLES 

Figure  1 .  GBS  Program  Timeline . 13 

Figure  2.  GBS  Phase  II  Payload  Capabilities . 14 

Figure  3.  GBS  Phase  II  Coverage . 1 5 

Figure  4.  Generic  Reach  Back  Configurations . 17 

Figure  5.  GBS  Throughput  vs.  Back  Channel  Throughput  for  Single  Thread  User . ,21 

Figure  6.  GBS  -  UHF  DAMA  Reach  Back  Test  Configuration . 22 

Figure  7.  DirecDuo  Operation . 24 

Figure  8.  GBS  Without  and  With  IDM . 27 

Figure  9.  GBS  Reach  Back  Top  Level  View . 47 

Figure  10.  Ethernet  Message  Generator... . 53 

Figure  11.  IT-21  Unit  Capabilities . 54 

Figure  12.  Aggregated  Shipboard  Subnet  within  an  ATM  LAN . 56 

Figure  13.  Ethernet  Hub . 57 

Figure  14.  FYDP  SATCOM  Constellations . 58 

Figure  15.  ADNS  Block  for  CVN . 86 

Figure  16.  ADNS  Build  2 . 87 

Figure  17.  GBS  Block  Diagram  -  Wahiawa,  HI . 91 

Figure  18.  Forward  Channel  Analysis . 93 

Figure  19.  Reach  Back  Channel  Analysis . 94 

Figure  20.  Sample  Attribute  Analysis  Break  Down . 94 

Table  1.  Example  Extend  Limitations . . . 41 

Table  2.  Summary  of  Model  Assumptions . 45 

Table  3.  Default  User  Priority  Assignments . 54 

Table  4.  Default  Message  Classification  Assignments . 55 

Table  5.  Default  Port  Priority  Assignments . 55 

Table  6.  Default  Product  Request  Assignments . 55 

Table  7.  DSCS  III  Satellite  Positions . 61 

Table  8.  Total  Time  to  Complete  UHF  DAMA  Reach  Back . 79 

Table  9.  Example  Single  Transponder  Broadcast  Allocation . 89 

Table  10.  SBM  Port  Data  Rates  (Mbps)  for  GBS-DISN  Access . ...90 

Table  11.  Time  Stamps  (Relative  Mean)  for  GBS  RB  Model . 96 

Table  12.  Roimd  Trip  Times  for  GBS  RB  Products . 97 

Table  13.  Ship  Roxmd  Trip  Times  for  GBS  RB  Model . 98 

Table  14.  Round  Trip  Times  for  All  Back  Channels  for  GBS  Delivered  Products . 98 


ix 


X 


ACKNOWLEDGEMENT 


The  author  would  like  to  acknowledge  Professors  Dan  Boger,  Carl  Jones  and  John 
Osmundson  for  their  insightful  comments  and  patience.  In  addition,  special  thanks  to 
Tim  Krout  for  his  innovative  ideas  and  technical  guidance. 

The  author  owes  thanks  to  several  other  people  for  the  completion  of  this  project. 
Thanks  to  Dave  Rouse,  George  Yungk  and  the  GBS  Joint  Program  Office  and  the  Naval 
Research  Laboratory  (Transmission  Technology  Division)  for  a  worthwhile  experience 
tour.  Thanks  to  the  Naval  Space  Command  for  funding  the  trip. 

Additional  thanks  to  Professor  Rex  Buddenberg  and  the  Internet  to  Sea  colleagues 
(Howard,  Joan,  Tanya,  Mike  and  Greg)  for  their  research  assistance.  Thanks  also  to 
Larry  Gloss  for  his  editorial  comments  and  words  of  encouragement. 

The  author  reserves  a  very  special  thanks  to  all  his  “Moms”  for  their  imending 
support.  Likewise,  the  author  expresses  his  biggest  thanks  to  his  wife  Marcy  for  her 
unselfishness,  devotion  and  love. 


XI 


xii 


I. 


INTRODUCTION 


A.  PURPOSE  OF  RESEARCH 

The  Global  Broadcast  Service  (GBS)  and  its  ability  to  provide  multi-megabit  per 
second  (Mbps)  data  rates  will  revolutionize  military  communications  by  dramatically 
increasing  the  dissemination  of  information  to  both  operational  commanders  and  lower 
echelon  users.  History  has  shown,  however,  users  quickly  can  become  overloaded  with 
data.  Even  without  the  GBS,  users  have  often  received  information  that  is  irrelevant  or  is 
not  used  (because  it  was  not  known  that  the  information  was  available).  The  fielding  of 
the  GBS  only  exacerbates  this  problem,  especially  if  there  is  no  process  to  address 
information  dissemination  management  (IDM).  The  GBS  offers  an  extremely  robust 
communications  delivery  capability,  but  unless  the  information  is  managed  carefully,  it 
may  create  as  many  problems  as  it  solves. 

In  addition,  the  requirement  to  give  commanders  positive  control  over  limited 
communications  resources  often  competes  with  the  requirement  to  give  users  immediate 
access  to  relevant  information.  At  any  given  moment  decision  makers  and  users  are 
competing  for  limited  resources.  This  dilemma  is  especially  pertinent  to  the  capabilities 
and  challenges  offered  by  GBS.  For  example,  the  commander  can  exercise  more  control 
by  "smart  pushing"  GBS  products.  However,  the  user  can  ensure  more  information 
relevancy  by  interactively  requesting  products  via  "pull".  A  balance  between  the  two 
methods  of  information  delivery  must  be  found  in  order  to  make  the  GBS  a  significant 
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factor  in  achieving  Joint  Vision  2010’s  goal  of  information  superiority  and  full  spectrum 
dominance. 

The  balance  between  smart  push  and  user  pull  is  dynamic  and  depends  on  such 
factors  as  geography,  communication  resources,  and  tactical,  operational  and  strategic 
conditions.  Thus,  it  is  just  as  important  to  develop  a  process  to  identify  the  balance  as  it 
is  to  find  the  balance  itself  This  thesis  provides  a  tool  to  analyze  and  develop  the  GBS 
IDM  process  by  using  modeling  and  simulation  to  implement  recent  critical  technologies 
(primarily  asymmetric  networking)  into  the  GBS  architecture. 

B.  SCOPE  OF  THESIS 

The  GBS  model  developed  in  this  project  uses  a  relatively  inexpensive 
commercial  off-the-shelf  (COTS),  object-oriented  modeling  tool.  This  tool,  Extend  by 
Imagine  That!  Incorporated,  costs  less  than  $1000  and  operates  on  a  PC  (personal 
computer).  [Imagine  That!]  Simulation  of  the  model  provides  an  initial  assessment  of 
various  reach  back  channels.  The  assessments  were  augmented  by  qualitative  research 
efforts.  Experiments  and  demonstrations  that  were  drawn  upon  were  conducted  by  the 
Naval  Research  Lab  (NRL),  the  Naval  Postgraduate  School  (NPS),  and  the  National 
Reconnaissance  Office  Operational  Support  Office  (NRO/OSO).  As  a  result,  this 
project’s  work  serves  as  a  foundation  for  future  GBS  IDM  process  development.  The 
GBS  Extend  model  is  one  tool  that  can  be  used  for  this  development.  Likewise,  any 
subsequent  analysis  imdoubtedly  will  assist  theater  information  management  (TIM)  in 
finding  the  right  balance  of  smart  push  and  user  pull  in  various  real  world  situations. 


It  should  be  noted  that  the  high-powered  GBS  space  segment  is  designed  upon 
relatively  new  technology.  The  GBS  ground  segment,  however,  is  designed  on 
innovative,  cutting-edge  technology.  The  groimd  segment  must  continually  utilize  the 
latest  information  networking  advancements  in  order  to  enable  the  transformation  of  GBS 
into  a  fully  interoperable,  end-to-end  system.  Two  key  technologies  are  implemented 
into  the  GBS  Extend  model  in  order  to  improve  the  IDM  process.  One  technology  is 
satellite-based  asymmetric  networking.  In  the  GBS  program,  this  technology  is  coined 
as  "GBS  reach  back”  (RB).  A  second  technology  is  automated  radio-wide  area  network 
(radio-WAN)  management.  The  Navy  demonstrates  this  technology  with  ADNS 
(Automated  Digital  Network  System).  The  implementation  and  maturation  of  these  two 
technologies  are  critical  for  making  the  simplex  GBS  system,  an  efficient,  virtual  two- 
way  interactive  system  which  will  be  conducive  to  the  growing  World-Wide-Web 
(WWW)  browsing  nature  of  information  users. 

Enabling  efficient,  interactive  dialogue  between  the  information  user  and 
producer,  via  reach  back  and  ADNS,  alleviates  some  of  the  burden  on  the  GBS  TIM. 
Nevertheless,  the  information  management  question  still  remains:  "What  is  the  right  mix 
of  pre-identified  and  user-initiated  broadcast  products?"  As  mentioned  before,  the  answer 
is  dynamic  and  depends  on  a  variety  of  factors.  This  project  uses  Extend  to  develop  a 
model  which  can  later  be  used  to  analyze  these  factors.  Unfortimately,  Extend  effectively 
looks  at  the  physical  nature  of  the  GBS  information  flow,  but  does  not  conclusively 
address  the  qualitative  nature  of  information  relevancy.  This  deficiency  should  be 
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alleviated  by  integrating  conclusions  from  both  the  Extend  model  simulations,  lessons 
learned  from  past  and  ongoing  GBS  reach  back  experiments  and  demonstrations,  and  real 
■world  GBS  data  flow  analysis. 

A  major  thrust  of  this  project  is  the  initial  analysis  of  GBS  back  channel 
performance  in  a  simulated  environment  of  multiple  users  with  multiple  reach  back 
channels.  The  project  model  assumes  the  implementation  of  ADNS  and  GBS  reach  back 
and  involves  Information  Technology-Twenty  First  Century  (IT-21)  standards  for  Paciflc 
area  of  responsibility  (AOR)  US  Naval  forces.  Information  flow  is  representative  for  a 
“well-equipped”  early  millennium  carrier  battle  group  (CVBG)  in  transit  in  the  Pacific 
AOR.  It  is  hoped  that  ongoing  GBS  reach  back  research  and  future  GBS  real  world 
traffic  analysis  can  be  used  to  support  and  improve  the  model  developed  in  this  project. 

C.  THESIS  ORGANIZATION 

To  be  qualified  to  develop  an  asymmetric  network  model  of  GBS  with  automated 
radio  frequency  management,  an  imderstanding  of  the  GBS,  reach  back  (including  the 
ADNS  interface),  and  IDM  is  required.  Chapter  II  (Background)  provides  a  brief 
description  of  these  requisite  topics.  Once  the  basics  are  kno’wn,  the  GBS  concept  of 
operations  (CONOPS)  and  its  application  in  various  AORs  must  be  understood.  Chapter 
III  (GBS  CONOPS)  outlines  the  Mission  Need  Statement  (MNS),  Operational 
Requirements  Document  (ORD),  and  GBS  Joint  CONOPS.  Appendix  D  outlines  the 
various  theater  Commanders-in-Chief  (CINC)  CONOPS  draft  documents.  Chapters  II 
and  III  are  for  the  reader’s  reference  and  provide  essential  backgroimd  information  for  the 


4 


reader  unfamiliar  with  the  GBS.  Chapter  III  and  Appendix  D  will  be  of  particular  interest 
to  those  interested  in  comparing  the  CINC  philosophies  on  GBS  use. 

The  details  of  the  project  are  provided  after  the  background  chapters  with  the 
modeling  and  simulation  process  and  analysis  being  described  in  Chapter  IV,  including  a 
discussion  of  the  RB  channels  modeled  and  the  ADNS  interface.  The  Extend  Block 
Definitions  (Appendix  F)  should  prove  helpful  when  reviewing  this  chapter.  A  summary 
of  the  general  impacts  of  GBS  reach  back  and  specific  back  channel  assessments  are 
presented  in  Chapter  V.  Chapter  V  also  provides  recommended  areas  for  model 
improvement  and  further  study.  The  last  two  appendices  (Appendixes  J  and  K)  are  the 
glossary  and  acronym  list,  respectively.  It  is  recommended  that  these  two  appendices  be 
made  readily  available  for  frequent  reference  during  review  of  this  document. 
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IL  BACKGROUND 


A.  GBS  OVERVIEW 

1.  History 

The  GBS  concept  began  with  the  launch  of  the  first  direct  broadcast  satellite 
(DBS)  in  1974  and  with  the  subsequent  introduction  of  home  satellite  television  (TV) 
service  in  California  in  1976.  [Morrill]  The  C-Band  satellites  of  these  early  television 
receive-only  (TVRO)  systems  used  approximately  24  low-powered  single-channel 
transponders.  As  a  result,  TVRO  consumers  had  to  use  large,  relatively  expensive  dish 
antennas  (typically  6  to  12  feet)  to  receive  adequate  reception.  [Andrews]  Since  these 
systems  offered  a  limited  number  of  broadcast  TV  channels  and  required  the  use  of  large, 
expensive  earth  station  terminals,  the  military  initially  did  not  envision  the  technology  as 
a  source  for  meeting  multiple  communications  needs.  Nevertheless,  the  idea  of  injecting 
one  signal  to  a  satellite  and  broadcasting  to  multiple  widely  dispersed  “end-level  users” 
simultaneously  was  successfully  conceived  and  proven. 

The  allocation  of  higher  frequencies  for  DTH  (direct-to-home)  use  and  the 
advancements  in  satellite  and  communications  technology  led  to  another  generation  of 
satellite  TV  systems  in  1994.  These  high  power  Ku-band  DBS  systems  enabled 
consumers  to  receive  broadcast  TV  with  less  costly,  18-inch  dish  antenna  systems. 
Likewise,  digital  video  compression  allowed  DBS  systems  to  broadcast  more  channels 
from  one  transponder.  The  first  satellite,  a  joint  venture  of  United  States  Satellite 


7 


Broadcasting  (USSB)  and  DirecTV,  was  capable  of  broadcasting  75  TV  channels  to  the 
continental  United  States  (CONUS).  USSB  and  DirecTV  provided  DBS  service  to  over 
one  million  customers  in  only  the  first  year  of  operation.  [Godwin] 

That  same  year,  the  Defense  Science  Board’s  (DSB)  study  entitled,  Information 
Architecture  for  the  Battlefield,  recommended  that  the  utility  of  DBS  be  looked  at  to 
improve  information  dissemination  to  all  levels  of  fighting  forces.  [Morrill]  This 
recommendation  followed  the  earlier  1 992  report,  The  Conduct  of  the  Persian  Gulf  War 
-  The  Final  Report  to  Congress,  which  highlighted  that  current  military  and  civilian 
satellite  communication  systems  were  oversubscribed  and  “limited  in  ability  to  provide 
responsive,  high  capacity  communications  to  deployed,  mobile  tactical  units.”  [MNS] 
Consequently,  the  Department  of  Defense  (DoD)  urgently  needed  to  find  some 
communications  solutions.  The  result  was  the  use  of  DBS  as  a  partial  solution  to  the 
DoD’s  communications  deficiencies. 

Leveraging  DBS  technology  is  viable  for  the  military  for  many  compelling 
reasons.  Word-wide  coverage,  low  cost,  multimedia  data,  small  terminals,  and  cutting- 
edge  technology  are  just  a  few  reasons.  For  instance,  commercial  DBS  technology 
currently  allows  a  consumer  to  get  over  200  channels  of  high  quality  digital  television 
and  up  to  400  kilobit  per  seconds  (kbps)  of  Internet  download  service  from  one  21 -inch 
elliptical  receive  antenna.  In  addition,  set  up  costs  can  be  as  low  as  $500  and  dual  video¬ 
data  service  as  low  as  $50  per  month.  [DirecDuo]  Furthermore,  increased  consumer 
demand  will  drive  costs  down,  and  information  technology  evolution  will  translate  to 
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more  capability  (increased  number  of  channels  and  higher  data  rates).  Likewise,  with  the 
implementation  of  an  open  architecture  and  a  streamlined  acquisition  process,  the  GBS 
Joint  Program  Office  (JPO)  can  immediately  field  DBS  technology  to  military  users 
while  capitalizing  on  the  latest  information  and  networking  advancements  in  the 
commercial  sector.  Hence,  DBS  leveraging  becomes  a  smart,  highly  efficient  way  of 
quickly  introducing  low-cost,  cutting-edge  commimications  to  highly  mobile  and 
dispersed  military  units. 

To  leverage  technologies  like  DBS,  the  military  uses  advanced  concept 
technology  demonstrations  (ACTDs).  ACTDs  help  to  meet  critical  military  needs  by 
quickly  designing,  demonstrating,  proving,  and  fielding  new  technologies  to  the 
battlefield.  An  example  of  an  ACTD  that  helped  fuel  the  GBS  program  is  the  Battlefield 
Awareness  and  Data  Dissemination  (BADD)  ACTD.  BADD  provides  the  tools  to  obtain 
information  superiority  in  support  of  the  Bosnia  Command  and  Control  Augmentation 
(BC2A)  initiative.  The  IBS  (Joint  Broadcast  Service)  was  the  data  dissemination  portion 
of  the  BADD  ACTD  and  is  essentially  the  precursor  to  GBS.  [Morrill] 

In  January  1996,  the  JBS  took  the  COTS  broadcasting  technology  and  used  it  to 
augment  information  dissemination  in  the  United  States  European  Command 
(USEUCOM).  In  less  than  ninety  days,  the  JBS  leased  a  transponder  from  a  commercial 
DBS  system  and  used  it  to  inject  critical  information  to  units  involved  in  Operation  Joint 
Endeavor  (Bosnia).  [Morrill]  Meanwhile,  the  GBS  test  bed  at  the  NRL  (later  moved  to 
the  Pentagon  with  the  JBS)  was  also  set  up  and  researching  the  development  of  DBS 
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technology.  The  GBS  test  bed,  the  JBS  and  the  commercial  transponder  leases  comprise 
what  is  considered  GBS  Phase  1. 

Another  concurrent  development  involved  the  Navy’s  use  of  C-band  satellites  to 
increase  bandwidth  to  the  fleet.  The  idea  originated  from  a  1991  master’s  thesis  from  the 
Naval  Postgraduate  School  (NPS),  and  the  project  is  now  known  as  Challenge  Athena 
(CA).  CA  first  started  aboard  the  USS  GEORGE  WASHINGTON  (CVN  73)  in  October 
1991  and  delivered  simplex  data  (mostly  imagery).  By  late  1992,  CA  was  providing 
duplex  data  rates  of  up  to  1 .544  Mbps.  The  use  of  newer  satellites  in  CA  III  will  provide 
up  to  3  Mbps.  [Hampton]  With  Challenge  Athena,  wideband  commercial  satellites 
provide  the  increased  bandwidth  that  is  not  allocated  from  the  DSCS  III  (Defense 
Satellite  Communications  System  III)  satellites.  The  additional  surge  capacity  of  CA  has 
given  commanders  aboard  big  deck  Navy  ships  the  flexibility  to  support  today’s 
bandwidth  intensive  mission  requirements.  It  is  not  hard  to  imderstand  why  Naval 
operational  commanders  quickly  came  to  demand  CA  service  for  their  deployments.  The 
biggest  communications  pipe  available  next  to  CA  is  DSCS  SHF  (super  high  frequency). 
The  division  of  SHF  resources  to  the  four  Services  and  to  the  primary  agencies  leaves  the 
apportionment  to  the  big  deck  Navy  ships  at  768  kbps  maximum  (often  less).  It  should 
be  noted,  however,  that  DSCS  III  SEEP  (Service  Life  Extension  Program)  will  provide 
up  to  7  Mbps  (for  7-foot  anteima  users).  [Lindberg]  Clearly,  CA  is  a  successful 
demonstration  of  the  military  use  of  commercial  satellite  technology  in  attempt  to  answer 
the  operational  demand  for  greater  bandwidth. 
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Likewise,  since  1993,  NASA’s  ACTS  (National  Aeronautics  and  Space 
Administration  Advanced  Communications  Technology  Satellite)  program  has  been 
demonstrating  technologies  that  have  been  adopted  by  the  GBS  Phase  II  system.  For 
example,  the  ACTS  uses  high  data  rate,  large  bandwidth  Ka-band  transmission,  and 
steerable  multi-beam  high  gain  transmit  antennas,  which  is  similar  to  the  GBS  Phase  II 
payload.  Other  demonstrated  technologies  by  ACTS  include  on  board  digital 
regeneration,  nx64  kbps  circuit  svdtching,  and  real-time  circuit  allocation  processing. 
Although  the  ACTS  design  life  passed  in  1997,  the  satellite  continues  to  support  various 
communications  experiments  and  demonstrations.  [ACTS] 

Advancements  from  the  IBS  (including  BADD),  the  GBS  Phase  I  test  bed, 
Challenge  Athena,  and  ACTS  have  helped  shape  the  GBS  Phase  II  system  architecture. 
Consequently,  high  bandwidth  information  dissemination  via  the  GBS  employs  not  only 
the  commercial  DBS  technology,  but  also  the  lessons  learned  from  these  programs.  For 
example,  in  addition  to  the  advances  highlighted  above,  the  GBS  introduces  the  use  of 
multimedia  variable  rate  throughput,  transportable  uplinks  and  shipboard  terminals, 
which  were  demonstrated  by  at  least  one  of  the  programs  mentioned.  Undoubtedly,  the 
GBS  Phase  III  system  architecture  will  also  benefit  as  the  programs  continue  to  support 
experiments  and  demonstrations  and  provide  operational  lessons  learned.  With  the 
success  of  these  demonstration  programs  (combined  with  the  1992  report),  it  is  no 
surprise  that  the  GBS  program  received  keen  interest  from  the  highest  levels  of  the 
military.  As  such,  the  GBS  program  was  designated  an  Acquisition  Category- ID 
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(AC AT- ID)  program  and  given  an  aggressive  two  year  timeline  (from  process 
development  to  deployed  capability).  Historically,  an  ACAT-ID  timeline  averages  ten 
years.  [Delpino,  Leonard  and  Yarbrough] 

The  MNS  for  the  GBS  was  signed  on  03  August  1995,  the  ORD  was  signed  on  07 
April  1997,  and  the  contract  award  (for  the  ground  receive  suite)  was  granted  on  17 
November '  1997  to  Hughes  Information  Systems  of  Reston,  Virginia  (now  part  of 
Raytheon).  With  the  launch  of  Ultra  High  Frequency  Follow-On  number  8  (UFO-8)  on 
20  March  1998,  the  program  transitioned  into  Phase  II.  UFO-9  and  10  are  planned  to  be 
launched  in  October  1998  and  March  1999,  respectively.  [Delpino,  GBS  Program 
Update] 

The  Air  Force  is  the  System  Manager  (SM)  and  the  Navy  is  the  System 
Operations  Manager  (SOM)  for  the  GBS.  The  SM  is  responsible  for  the  funding  and 
execution  of  the  GBS  while  the  SOM  is  responsible  for  operation  and  maintenance  of  the 
GBS-configured  satellites,  the  SBMs  (satellite  broadcast  managers),  and  the  PIPs 
(primary  injection  points).  Likewise,  the  Army  is  responsible  for  the  TIPs  (theater 
injection  points)  and  their  CONOPS  development.  [SCOC] 

2.  Three  Phases  of  GBS 

As  shown  in  Figure  1,  the  GBS  life  cycle  is  divided  into  three  phases.  The  JBS, 
the  test  bed,  and  the  commercial  leases  make  up  Phase  I,  which  continue  operation  in 
order  to  provide  technology  and  CONOPS  development  and  lessons  learned.  The  JBS 
and  GBS  test  bed  uplink  facility  are  co-located  at  the  JIMC  (Joint  Information 
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Management  Center)  in  the  Pentagon,  but  the  test  bed  is  moving  to  Norfolk,  Virginia. 
Phase  II  utilizes  a  GBS  payload  riding  on  three  UFO  satellites  (UFO  8-10)  and  provides 
an  interim  capability.  Phase  III  is  planned  to  be  operational  in  2009.  It  will  have 
increased  numbers  of  transponders  and  spot  beams  per  satellite,  and  the  possibility  of 
duplex  Ka  capability.  The  expected  five  satellites  for  GBS  Phase  III  are  speculated  to 
have  seven  spot  beams  and  twelve  transponders  each,  for  a  maximum  of  270  Mbps  of 
throughput  per  satellite.  [PACOM]  In  addition,  more  users  will  have  access  to  the  GBS, 


e.g.,  users  with  “manpackable”,  highly  mobile  or  airborne  receive  suites. 


Figure  1 .  GBS  Program  Timeline 
[Delpino,  GBS  Program  Update] 


To  bridge  any  gap  between  Phase  II  and  Phase  III,  three  SHF/Ka  Gapfiller 
satellites  (launched  between  fiscal  years  2004  and  2005)  and  commercial  leases  will  be 


used  to  augment  the  GBS  interim  UFO  satellites.  [GBS] 

This  thesis  focuses  primarily  on  GBS  Phase  II,  the  interim  GBS  architecture.  The 
model  is  based  on  the  configuration  of  the  GBS  payloads  hosted  on  the  UFO  satellites. 
Appendix  A  shows  the  GBS  payload  functional  components  and  highlights  the  various 
configuration  schemes  depicted  in  Figure  2.  Based  on  the  combination  of  the  Primary 
Injection  Points  (PIPs),  Theater  Injection  Points  (TIPs),  receive  antennas  (2), 
transponders  (4)  and  spot  beams  (3),  various  data  rates  can  be  achieved.  The  maximum 
data  rate  is  96  Mbps  (24  Mbps  for  each  of  four  data  streams  using  two  500  nautical  mile 
[nm]  spot  beams).  However,  if  2000  nm  spot  beam  coverage  is  required,  1.544  Mbps  is 
the  maximum  throughput  for  that  wide-beam  area.  [GBS] 
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Figure  2.  GBS  Phase  II  Payload  Capabilities 
[McAlum] 
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3. 


GBS  Phase  II  System  Architecture 


The  spot  beams  can  be  moved  within  the  satellites  field  of  view  (FOV)  within 
three  minutes  (the  ORD  requires  a  minimum  of  ten  minutes),  but  typically  will  be  done 
within  eight  minutes.  [SCOC]  To  reconfigure  the  transponders  (e.g.,  switch  from  the 
normal  configuration  of  three  24  Mbps  streams  and  one  1.544  Mbps  stream  using  three 
spot  beams  to  four  24  Mbps  streams  using  two  spot  beams),  a  delay  of  hours  to  days  is 
expected  depending  on  the  availability  of  UFO  Telemetry,  Tracking,  and  Commanding 
(TT&C).  [GBS] 

The  nominal  coverage  of  the  three  geosynchronous  UFO  satellites  is  latitudes  65® 
South  to  65°  North  (see  Figure  3).  The  coverage  for  most  of  CONUS  is  gapped  and  will 
be  augmented  by  leased  satellites  (and  ACTS  if  available).  [GBS] 


Figures.  GBS  Phase  II  Coverage 
[Delpino,  GBS  Program  Update] 
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B.  GBS  REACH  BACK 


1.  Description 

“GBS  reach  back”  describes  the  satellite-based,  highly  asymmetric  network 
involving  the  GBS  satellite  segment,  groimd  segment,  and  connected  end  users.  An  end 
user  requests  information  via  an  alternative  communication  channel,  which  is  processed 
by  the  GBS  SBM  (to  get  the  requested  information  from  the  destination).  The  SBM  then 
relays  the  requested  product  to  the  satellite  segment  for  broadcast  back  to  the  end  user  via 
a  GBS  RBM  (receive  broadcast  management)  suite.  The  relatively  low  throughput  of  the 
request  channel  (as  low  as  2.4  kbps)  compared  to  the  large  throughput  of  delivery  charmel 
(up  to  24  Mbps)  makes  the  GBS  reach  back  architecture  a  highly  asymmetric  network. 

Since  reach  back  is  accomplished  by  any  means  of  communication  available  that 
provides  connectivity  from  the  user  in  question  to  the  GBS  SBM,  reach  back  (in  the  most 
archaic  sense)  can  be  accomplished  by  message  courier,  phone  call  or  electronic  mail 
(Email).  Figure  4  shows  sample  configurations  for  an  end  user  to  request  information 
(via  dial  up,  via  Defense  Information  Infrastructure,  DII,  and  via  satellite 
communications,  SATCOM).  Example  transmission  systems  for  dial  up  include  cellular 
phone  and  plain  old  telephone  system  (POTS).  Example  DII/DISN  (Defense  Information 
System  Network)  back  channels  include  NIPRNET  (Non-secure  Internet  Protocol 
Routing  Network,  SIPRNET  (Secure  Internet  Protocol  Routing  Network),  and  JWICS 
(Joint  Worldwide  Intelligence  Communications  System).  SATCOM  reach  back  could 
utilize  commercial  wide  band  (i.e..  Challenge  Athena  and  Teledesic),  mobile  satellite 
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services,  MSS  (i.e.,  Inmarsat  B,  Iridium,  Globalstar,  and  ICO),  or  military  SATCOM, 
MILSATCOM  (i.e.,  SHF,  EHF  [Extra  High  Frequency]  and  UHF).  Another  reach  back 
possibility  not  depicted  in  Figure  3  is  line  of  sight  (LOS)  communications  systems,  i.e., 
HF  [High  Frequency]  or  UHF).  HF  could  be  used  for  long  haul  communications  (up  to 
500  nautical  miles)  at  2.4  kbps,  but  another  possible  implementation  is  to  use  HF  as  a 
relay  back  to  a  big  deck  ship  and  go  into  the  DISN  from  SHF  or  Challenge  Athena.  This 
HF  relay  is  incorporated  in  the  Extend  model  and  is  similar  to  the  Digital  Wideband 


Transmission  System  (DWTS)  for  amphibious  forces  (using  UHF  relay). 


Figure  4.  Generic  Reach  Back  Configurations 


[ACOM] 


The  GBS  reach  back  information  flov^^  is  not  much  different  from  the  way  a  home 


user  surfs  the  Internet  via  an  ISP  (Internet  Service  Provider).  In  GBS  reach  back,  the 
TIM  (Theater  Information  Management)  server/router  acts  as  the  warrior’s  ISP,  but  the 
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information  is  delivered  via  the  GBS  instead  of  going  back  via  the  requested 
conraumication  channel.  Of  course  the  home  user  normally  is  using  a  POTS  line  and  the 
PSTN  (public  switched  telephone  network)  to  reach  the  ISP.  The  warrior,  on  the  other 
hand,  uses  whatever  communication  channel  is  available,  often  satellite  communications. 

While  web  browsing,  an  Internet  user  normally  utilizes  hyper  text  transfer 
protocol  (HTTP),  which  is  a  transmission  control  protocol/Intemet  protocol  (TCP/IP) 
application.  TCP/IP  provides  the  rules  for  communication  transfer  and  assumes  a  bi¬ 
directional  communication  link.  However,  to  use  TCP/IP  with  the  one-way  GBS  system, 
a  technical  solution  is  needed  to  assimilate  virtual  two-way  communication.  Many 
organizations  and  experiments  address  this  “tricking”  or  “bending”  of  the  TCP/IP 
protocol  in  order  to  make  a  one-way  system  operate  virtually  like  a  two-way  system. 
Completing  the  communications  loop  for  a  one-way  system  like  GBS,  makes  it  an  end- 
to-end  system.  DirecPC  is  a  commercial  example  of  how  reach  back  makes  a  one-way 
system  work  end-to-end.  Other  experiments  and  implementations  of  GBS  reach  back  are 
discussed  later  in  this  section. 

2.  Four  Reach  Back  Connectivity  Modes 

Coimectivity  modes  describe  the  degree  in  which  a  GBS  user  is  connected  with 
the  SBM  and  information  producers.  The  four  connectivity  modes  are  receive  only  (RO), 
manually  connected  (MC),  partially  coimected  (PC),  and  fully  coimected  (FC).  Receive 
suites  can,  depending  on  their  connectivity  mode,  offset  limitations  of  a  one-way  service. 
Each  coimectivity  mode  offers  different  benefits  to  the  user  and  different  levels  of 
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efficiency  for  GBS.  In  the  fully  or  partially  connected  mode,  the  receive  suite  (RBM) 
can  report  downlink  quality  to  the  SBM.  With  this  feedback  information  the  SBM  can 
adjust  the  broadcast  to  improve  user  reception  (e.g.,  adjust  data  rate,  schedule,  or 
coverage  area).  Likewise,  the  fully  connected  users  have  the  ability  to  query  producers 
and  information  providers  for  additional  amplifying  information.  [GBS]  All  users  in  the 
Extend  models  are  fully  connected.  Appendix  B  further  describes  the  differences  among 
the  four  receive  suite  connectivity  modes. 

3.  Reach  Back  Experiments 

a.  RB  in  Joint  Warrior  Interoperability  Demonstration  (JWID)  1996 

This  demonstration  used  a  2.4  kbps  EHF  MILSTAR  SATCOM  reach  back 

channel.  Users  requested  information  via  the  SIPRNET  using  a  web-like  interface.  This 
interface  sent  an  Email  to  the  information  source  once  the  user  selected  a  product  item 
from  the  workstation  software  menu.  Upon  receiving  the  Email  request,  the  information 
producers  wrapped  and  delivered  the  product  via  the  SIPRNET  to  the  GBS  uplink 
facility.  Request-to-receipt  cycle  time  took  three  to  five  minutes  (some  exceptions  took 
up  to  fifteen  minutes).  Poor  weather  conditions  at  the  uplink  facility  and  broadcast 
queue  delays  probably  attributed  to  the  longer  delivery  times.  [Roper] 

b.  Reach  back  at  the  Naval  Research  Lab  (NRL)  and  in  JWID  1997 

In  November  and  December  1996,  the  NRL  (with  assistance  from  DISA 
and  OSO)  demonstrated  a  mediiun  data  rate  (160  kbps)  and  high  data  rate  (1.288  Mbps) 
channel  capability  using  the  same  satellite  transponder  used  for  broadcast.  Simultaneous 
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occupation  of  the  reach  back  and  broadcast  signal  did  not  adversely  affect  the  GBS 
signal.  [NRL]  As  a  result,  the  NRO/OSO  used  this  single  transponder-back  channel 
concept  to  demonstrate  actual  “user  pull”  GBS-facilitated  information  requests  during 
JWID  1997.  The  1997  reach  back  channel  operated  at  40  kbps  and  used  direct  sequence 
spread  spectrum  (to  prevent  interference  to  adjacent  satellites).  A  1.2m  very  small 
aperture  terminal  (VSAT)  transmitted  the  reach  back  signal.  Request-to-receipt  cycle  time 
took  less  than  five  minutes  (some  exceptions  taking  up  to  40  minutes).  Broadcast  queue 
delays  probably  were  attributed  to  the  longer  delivery  times.  Also,  no  apparent 
correlation  between  file  size  and  delivery  time  was  observed.  Although  the  JWID  97 
demonstration  placed  into  action  the  1996  NRL  findings,  the  reach  back  concept  does  not 
correspond  with  the  developments  of  the  GBS  payload  on  UFO  satellites.  With  only  two 
receive  anteimas  (one  steerable),  the  GBS  Phase  II  system  does  not  support  user  reach 
back  via  the  same  satellite.  The  receive  antennas  are  used  solely  for  broadcast  signal 
injections  firom  one  PIP  and  multiple  TIPs  (if  within  350  nm  of  each  other).  [Arthur] 

c.  Naval  Research  Laboratory  (NRL)  Experiments 

In  December  1997  through  March' 1998,  the  Naval  Research  Laboratory 
combined  the  concept  of  GBS  reach  back  with  a  WWW-browsing  fimctionality.  This 
experiment  demonstrated  the  “user  pull”  of  data  using  the  GBS  system  and  standard 
TCP/IP  protocols.  Variable  data  rates  were  tested  from  2.4  to  64  kbps  to  simulate 
ubiquitous  back  channels  (e.g.,  POTS,  cellular  phone,  25-kHz  UHF  SATCOM,  and  the 
Planet  One  Data  Phone).  The  experiment  measured  forward  GBS  throughput  as  a 
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function  of  back  channel  data  rate.  To  gain  baseline  data  from  error-free  conditions,  the 
back  channels  were  hard-wired.  Figure  5  shows  the  results  of  these  tests.  The  increase  of 
back  channel  throughput  above  19.2  kbps  did  not  result  in  appreciable  increase  in  GBS 
throughput.  Likewise,  the  maximum  GBS  throughput  achieved  was  just  over  900  kbps, 
significantly  less  than  the  available  2  Mbps.  This  inefficiency  is  possibly  attributed  to 
TCP/IP  window  limitations  or  congestion  control.  Nevertheless,  the  efficiency  increases 
ivith  the  addition  of  TCP/IP  threads.  For  example,  two  28.8  kbps  back  channel  single¬ 
thread  users  could  both  get  900  kbps  throughput  (leaving  200  kbps  unused).  Likewise,  if 
a  third  user  was  added,  all  three  users  could  get  666  kbps  throughput  (using  the  entire  2 
Mbps  channel).  [Krout] 


GBS  2Mbps  TCP/iP 


—  HTTP  Throughput 

—  FTP  Throughput 
Router  Input 

—  Router  Output 


Backchannel  (Kbits/sec) 


Figure  5.  GBS  Throughput  vs.  Back  Channel  Throughput  for  Single  Thread  User  [Krout] 
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d.  Naval  Postgraduate  School: 

In  Junel998,  a  master’s  thesis  documented  the  NPS  GBS  reach  back 


experiment  using  25Khz  UHF  DAM  A  (Demand  Assigned  Multiple  Access).  The  NPS 
GBS  Phase  I  receive  suite,  the  Space  and  Naval  Warfare  Systems  Command’s  (SSC) 
ADNS  and  UHF  equipment,  and  the  GBS  test  bed  successfully  implemented  UHF 
DAMA  as  a  possible  alternative  for  user  reach  back.  The  experiment  setup  is  shown  in 
Figure  6. 


Figure  6.  GBS  -  UHF  DAMA  Reach  Back  Test  Configuration 


[Arthur] 

Although  successful,  the  long  latency  of  the  25  kHz  UHF  DAMA  reach 
back  channel  (attributed  to  the  protocol  framing  delays  and  the  geosynchronous  satellite 
round-trip  delay)  caused  inherent  problems  to  establishing  and  maintaining  a  TCP/IP  data 
connection.  To  make  the  TCP/IP  work,  a  third  party  system  is  required  to  “trick”  the 
latency  sensitive  TCP/IP  protocol.  The  experiment  used  ADNS  as  the  third  party  system. 


22 


[Arthur]  The  Extend  models  also  use  ADNS  to  carry  similar  functions  for  all  reach  back 
channels. 

e.  Reach  Back  in  JWID 1998 

In  July  1998,  the  NRO/OSO  and  NRL  built  on  the  web  browsing 
experiments  completed  earlier  in  the  year  by  NRL.  The  JWID  demonstration  used 
various  radio  frequency  (RF)  reach  back  channels  instead  of  hard-wired  back  channels. 
Web  browsing  via  various  reach  back  channels  such  as  POTS,  cellular  phone,  25-kHz 
UHF  SATCOM,  the  Planet  One  Data  Phone,  VS  AT  code  division  multiple  access 
(CDMA)  SATCOM  were  conducted  successfully  from  three  sites.  One  of  the  sites 
simulated  a  ship  configured  with  ADNS.  Unofficial  results  achieved  maximum  GBS 
throughputs  of  150  kbps  for  the  various  RF  back  channels.  Again,  some  of  this 
inefficiency  is  possibly  attributed  to  TCP/IP  window  limitations  or  congestion  control. 
Other  possible  factors  include  the  latency  and  BER  of  the  back  channels.  Nevertheless, 
just  as  discussed  previously,  the  efficiency  can  increase  to  one  hundred  percent  when 
additional  threads  are  added.  [Krout,  Goldstein  and  Solsman] 

4.  Commercial  Analogies  - 

DirecPC  and  DirecDuo  are  making  similar  developments  in  satellite-based 
asymmetric  networking.  In  addition,  the  Internet  Engineering  Task  Force  (IETF)  has 
sponsored  a  Unidirectional  Link  Routing  (UDLR)  working  group  to  look  at  integrating 
unidirectional  links  into  the  TCP/IP  dominated  Internet.  DirecPC  uses  consumer  phone 
connections  to  reach  back  to  either  a  separate  ISP  or  the  DirecPC  NOC  (network 
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operations  center),  which  acts  as  the  proxy  to  the  Internet.  The  request  is  then  forwarded 
to  the  destination  server  and  a  return  web  page  or  product  is  sent  back  to  the  NOC  for 
uplink  to  a  DirecPC  satellite.  [DirecPC]  The  broadcast  is  then  downlinked  back  to  the 
user’s  21 -inch  elliptical  receive  antenna  (see  Figure  7).  The  broadcast  data  rate  is  12 
Mbps,  but  the  actual  realized  throughput  to  the  consumer  is  up  to  200  or  400  kbps, 
depending  on  the  service  option  selected.  The  number  of  users  that  are  sharing  the  12 
Mbps  data  stream  dictates  what  each  users  actual  throughput  is.  [DirecDuo] 


Figure  7.  DirecDuo  Operation  [DirecDuo] 


The  UDLR  working  group  was  chartered  to  find  the  best  way  to  solve  the 
asymmetric  unidirectional  link  routing  problem.  They  have  proposed  a  link  layer 
tunneling  mechanism,  which  is  very  similar  to  the  DirecPC  and  government  research 
solutions.  The  March  1998  Request  for  Comment  (RFC),  “A  Link  Layer  Tunneling 
Mechanism  for  Unidirectional  Links,”  is  the  latest  draft  of  UDLR  findings.  More 
profound  solutions  for  asymmetric  networks  with  unidirectional  links  (e.g.,  new  or 
improved  protocols)  may  become  the  object  of  future  IETF  working  groups.  [UDLR] 

C.  INFORMATION  DISSEMINATION  MANAGEMENT  (IDM) 

Collecting,  organizing  and  presenting  information  about  the  battlespace  (in  a 

fashion  easily  imderstood  by  the  end  user)  reduces  uncertainty  and  empowers  effective 
decision-making.  To  avoid  information  overload  and  to  support  Joint  Vision  2010,  IDM 
implements  the  C4I  for  the  Warrior  concept  of  automated  smart  push  and  warrior  (user) 
pull.  [IDM]  An  effective  IDM  process  for  balancing  smart  push  and  user  pull  helps 
ensure  information  relevance  and  timeliness.  This  thesis  develops  the  tool  and  provides 
the  initial  analysis  for  future  researchers  to  look  at  the  balance  of  the  smart  push  and  user 
pull  paradigm. 

1.  Information  Management  (IM) 

Information  management  is  required  for  the  entire  intelligence  cycle  from 
planning  and  direction,  collection,  processing  and  exploitation,  production,  dissemination 
and  integration,  evaluation,  and  use.  [IDM]  IM  encompasses  all  three  levels  of  support 
(strategic,  operational,  and  tactical)  and  is  critical  for  achieving  information  superiority. 


( 
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2.  Information  Dissemination  Management  (IDM) 

Information  dissemination  management  is  the  subset  of  IM  that  concentrates  on 
information  awareness,  access,  and  delivery.  Optimizing  these  three  elements  give  the 
warfighter  “the  right  information  in  the  right  place  at  the  right  time.”  [IDM]  Awareness, 
access,  and  delivery  are  defined  in  Appendix  C.  Likewise,  effective  IDM  provides 
commanders  with  the  ability  to  implement  policy  and  maximize  scarce  resources.  To 
enhance  IDM,  ACTDs  are  conducted  (e.g..  Defense  Advanced  Research  Project  Agency’s 
[DARPA]  BADD  ACTD).  Command,  Control,  Communications,  and  Intelligence  (C4I) 
demonstrations  such  as  BADD  serve  to  provide  the  tools  to  improve  the  IDM  process. 
[IDM] 

3.  IM  and  IDM  Strategy  with  GBS 

Properly  implemented,  the  GBS  is  only  part  of  a  single  interactive  dissemination 
system  that  distributes  information  via  the  most  effective  and  efficient  communication 
paths.  GBS  IDM  functions  include  compiling,  cataloging,  caching,  distributing,  and 
receiving  GBS  broadcast  products.  [IDM]  To  fully  utilize  IDM,  the  GBS  must  have 
maximum  connectivity  with  the  DII/DISN.  This  cormectivity  makes  the  one-way  GBS 
an  end-to-end  system.  With  an  IDM-enhanced,  fully  integrated  GBS  architecture,  IM 
merely  uses  the  GBS  as  another  dissemination  path,  albeit  a  big  one.  [IBS] 

The  GBS  Mission  Needs  Statement  (MNS)  highlights  that  the  "GBS  is  an 
extension  of  the  DISN,  and  will  require  development  of  a  data  management  capability 
and  injection  scheme  in  parallel  with  the  space  segment.”  This  parallel  management 
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program  has  become  known  as  IDM.  The  MNS  further  states  that  “Data  management 
must  include  the  capability  to  access  and  retrieve  archived  data  as  well  as  provide  timely 
dissemination  of  requested  information.  Prioritization  procedures  that  allow  users  to 
receive  the  most  critical  information  first  and  a  method  for  responding  to  user  requests 
must  be  developed  and  implemented."  [MNS]  As  such,  Figure  8  depicts  what  GBS 
operations  would  be  like  without  and  with  IDM  implemented.  . 
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Figure  8.  GBS  Without  and  With  IDM 
[Lee] 

4.  Role  of  Theater  Information  Management  (TIM) 

The  TIM  (and  the  Integrated  Broadcast  Service  (IBS)  IME  for  tactical  broadcasts) 
oversees  the  automated  routing  of  data  in  order  to  enforce  policy  and  optimize  resources. 
The  TIM  functions  have  been  kept  as  simple  as  possible  in  order  to  minimize  maiming 
and  training  impacts  to  the  CINC.  [PACOM]  Identified  TIM  functions  include  directing 
GBS  operations,  coordinating  broadcast  schedule,  managing  apportioned  resources, 
identifying  new  products,  reviewing  and  validating  user  profile  data  base,  and  auditing 
user  pull.  The  TIM  audits  user  pull  in  order  to  better  predict  users'  needs  and  identify 
products  for  the  smart  push  part  of  the  broadcast.  [GBS] 
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The  United  States  Pacific  Command  (USPACOM)  GBS  CONOPS  (draft)  states, 
“No  one  person  or  organization  has  the  experience,  authority  or  manning  to  accomplish 
all  the  TIM  functions.”  As  a  result,  TIM  responsibilities  are  fulfilled  by  using  current 
processes  and  a  TIM  working  group  (formed  firom  existing  persoimel).  However,  the 
TIM  doesn't  replace  functions  within  the  CINCs,  but  instead  augments  CINC  capabilities. 
TIMs  are  coimected  through  the  DII  backbone  to  the  "major  networks  and  news 
services".  [PACOM] 

Similarly,  a  TIM  that  utilizes  a  decentralized,  “IDM  by  negation  concept" 
harnesses  the  full  power  of  technology  and  lets  the  users  have  access  to  everything  that 
their  allocated  bandwidth  permits.  Commanders  can  restrict  user  access  based  on  the 
latest  mission  priorities  and  subsequent  resource  allocations.  The  centralized  approach  of 
giving  users  access  (when  requested  and  approved)  adds  delay  in  verification  and 
validation.  This  delay  may  prevent  users  fi-om  getting  relevant  and  timely  information. 
However,  to  make  the  decentralization  of  the  GBS  IDM  work,  the  CINC  (and  even  large 
units)  must  promulgate  an  information  priority  instruction  that  augments  the  priorities 
listed  in  Chairman  of  the  Joint  Chiefs  of  Staff  Instruction  Draft  (CJCSI)  6250.01  • 
(currently  Memorandum  of  Policy  [MOP]  37).  An  augmented  priority  instruction 
forewarns  users  on  expected  information  access  restrictions,  which  may  have  to  be 
imposed  for  various  scenarios. 
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III.  GBS  CONCEPT  OF  OPERATIONS  (CONOPS) 


This  section  outlines  the  MNS,  ORD  and  GBS  Joint  CONOPS.  Appendix 
D  outlines  the  GBS  CONOPS  for  various  CINCs.  Ideally,  the  CINC  CONOPS  also  serve 
as  annexes  to  the  GBS  Joint  CONOPS.  The  outlines  are  broken  up  to  answer  the 
following  questions: 

•  What  must  the  GBS  do? 

•  How  does  the  GBS  provide  information? 

•  What  are  some  key  GBS  requirements? 

•  What  are  some  key  GBS  elements  for  successful  implementation? 


A.  MISSION  NEEDS  STATEMENT  (MNS) 


The  MNS  outlines  user  requirements.  Specifically,  the  MNS  for  GBS  responds  to 
the  call  to  “create  an  interoperable  ‘system  of  systems’  geared  toward  enhanced  C4I.” 
[MNS]  The  follovring  outline  organizes  key  points  in  the  MNS  that  relate  to  this  thesis. 
The  reader  is  reminded  that  the  outline  contains  direct  content  from  the  MNS  and  is 
merely  organized  by  the  author  for  the  reader’s  reference. 

1 .  What  must  the  GBS  do? 

-  Improve  information  transfer  to  deployed  forces  and  free  capacity  on 
existing  systems  for  growing  two-way  C4I  requirements. 

Support  the  tenets  of  "C4I  for  the  Warrior"  via  the  concepts  of  “smart 
push”  and  “user  pull”. 

-  Act  as  an  extension  to  the  DISN.  However,  the  GBS  is  a  secondary 
means  of  communication  and  is  vulnerable  to  information  warfare 
(IW)  attack. 
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-  Integrate  with  existing  and  planned  in  theater  and  centralized  C4I 
systems  to  the  maximum  extent  possible  (e.g.,  Intelink,  GCCS,  United 
States  Imagery  System  (USIS),  Defense  Message  System  (DMS),  and 
the  DISN). 

-  Use  interface  methods  (i.e.,  ATM,  IP  or  other  widely  accepted  data 
transfer  standards)  that  seamlessly  support  the  GBS  as  a  means  of  data 
transmission,  while  avoiding  proprietary  solutions. 

2.  How  does  the  GBS  provide  information? 

-  Uses  “smart  push”  which  is  the  portion  of  the  GBS  broadcast  that 
provides  “packages  of  information  services”  that  may  be 
predetermined  based  on  existing  and  known  user  mission  and 
operational  requirements. 

-  Uses  “user  pull”  which  is  the  portion  of  the  GBS  broadcast  that  is  the 
result  of  user  requests  for  ad  hoc  information  requirements  via 
existing/planned  communication  architectures  (e.g.,  DSCS,  UHF, 
MILSTAR,  commercial  PCS). 

3.  What  are  some  key  GBS  elements  for  successful  implementation? 

-  Effective  management  procedures  and  robust  infrastructure,  which 
support  retrieval,  injection,  and  distribution  of  broadcast  information. 

-  The  ability  of  users  to  tailor  the  broadcast  to  satisfy  emergent 
requirements. 

-  The  minimization  of  GBS  manpower  and  personnel  requirements  and 
the  operation  of  the  GBS  with  resources  within  the  existing  force 
structure. 


B.  GBS  ORD 

The  ORD  provides  the  system  requirements  that  are  derived  from  the  MNS  user 
requirements.  Specifically,  the  ORD  identifies  the  Joint  Requirements  Oversight  Council 
(JROC)  approved  GBS  Phase  III  requirements  key  performance  parameters  (KPPs).  The 
following  outline  highlights  key  points  in  the  ORD  that  relate  to  this  thesis.  The  reader  is 
reminded  that  this  outline  contains  direct  content  from  the  ORD  and  is  merely  organized 
by  the  author  for  the  reader’s  reference. 
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Appendix  E  also  provides  the  initial  receive  suite  fielding  plan  as  described  in  the 
ORD.  It  should  be  noted  that  there  are  two  classifications  of  ground  receive  suites:  fixed 
ground  receive  suites  (FGRS)  and  transportable  ground  receive  suites  (TGRS).  In 
addition,  there  are  seven  different  configurations  based  on  the  users  capabilities  and 
needs.  These  configurations  vary  in  number,  type  of  data  (e.g.,  Ethernet,  serial  or 
asynchronous  transfer  mode),  and  level  of  classification.  Appendix  E  illustrates  these 
configurations. 

1 .  What  must  the  GB  S  do? 

-  Provide  worldwide,  high  capacity,  one-way  transmission  of  a 
variety  of  data,  imagery,  and  other  information  in  support  of  joint 
forces.  Initial  worldwide  coverage  is  from  65°  North  latitude  to  65° 
South  latitude,  180°  West  to  180°  East  longitude.  Final  global 
coverage  is  from  90°  North  to  65°  South  latitude,  180°  West  to  180° 
East  longitude. 

-  Transmit  high  data  rate  bit  streams  from  a  limited  number  of  fixed 
and  deployable  injection  terminals,  which  are  controlled  by  the 
CINCs  and  managed  by  the  broadcast  management  segment  in 
each  satellite’s  field  of  view. 

-  Receive  and  send  information  products  from  many  distributed 
locations  via  the  broadcast  management  segment. 

-  Integrate  fully  into  the  Defense  Information  Infrastructure  (DII)  by 
connecting  into  the  existing  and  future  commimications 
architecture  through  established  DISN  gateways  (when 
practicable). 

-  Act  as  a  non-critical  command  and  control  system,  which 
incorporates  minimal  survivability  and  hardening  features.  Critical 
command  and  control  information  products  still  may  be 
transmitted  over  the  GBS,  but  not  as  a  primary  means. 

2.  How  does  the  GBS  provide  information? 

-  Uses  the  SBM  to  accept,  coordinate,  and  package  (if  required), 
information  (general  broadcast  products,  smart  push  products,  user 
pull  products)  from  national  and  theater  sources  to  be  broadcast 
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based  on  the  direction  and  priorities  of  the  supported  CINC, 
commanders,  and  their  functional  users. 

-  Uses  “smart  push,”  which  constitutes  the  standard  products  and 
theater  tailored  information  that  are  placed  on  a  broadcast  as  they 
become  available,  in  accordance  with  established  user  needs  and 
priorities,  and  in  conformance  with  the  CINC’s  dissemination 
policy 

-  Uses  “user  pull,”  which  includes  other  information  products  that 
are  one-time  needs  identified  by  a  user  in  response  to  operational 
circumstances.  The  GBS  user  pull  requests  for  specific 
information  utilize  other  communications  systems  from  the  users 
to  the  information  source,  TIM,  or  SBM.  The  impact  of  these 
requests  on  existing  tactical  and  strategic  communications  systems 
are  minimized  with  user  profiles. 

3 .  What  are  some  key  GBS  requirements? 

’  -  Application  of  CINC  dissemination  priorities  to  information 

■  destined  for  broadcast  in  the  AOR,  and  the  coordination  of  this 
effort  between  the  SBM  and  the  Theater  Information  Managers 
(TIMs). 

-  Satisfaction  of  user  requests  (forwarded  by  the  TIM),  which  are 
unable  to  be  satisfied  by  other  means,  and  the  coordination  of  this 
effort  between  the  SBM,  the  TIM(s)  and  the  information 
producers. 

Interface  protocols  and  standards  that  allow  information  producers 
to  submit  information  in  a  form  acceptable  by  the  SBM  for  GBS 
broadcast. 

SBM  capability  to  conduct  both  transmit  management  and  receive 
management  functions.  The  transmit  function  will  manage  the 
information  flow  to  the  appropriate  injection  point  for  transmission 
to  the  satellite.  The  receive  function  will  support  the  filtering  of 
user  determined  relevant  information  from  the  broadcast  streams 
and  the  dissemination  of  the  receiver  information  from  receive 
suites  to  end  users’  servers  or  application. 

-  PIP  capability  to  uplink  up  to  94  Mbps  to  the  UFO  GBS  space 
segment. 

-  TIP  capability  to  uplink  up  to  24  Mbps  to  the  UFO  GBS  space 
segment  (6  Mbps  for  Phase  II  threshold).  Three  TIPs  will  be 
fielded  during  Phase  II  and  fourteen  will  be  fielded  during  Phase 
III. 


32 


-  RBM  (receive  broadcast  manager)  capability  to  provide  automatic 
iminterrupted  power  for  20  minutes  when  power  fails  (10  minutes 
for  Phase  II  and  III  threshold). 

-  RBM  capability  to  adjust  the  receive  data  rate  automatically  within 
10  seconds  when  there  is  a  change  in  the  broadcast  data  rate. 

-  RBM  capability  to  receive  four  transponder  streams 
simultaneously  from  a  single  satellite  (one  transponder  data  stream 
at  a  time  for  Phase  II  threshold). 

-  RBM  capability  to  operate  in  an  unattended  mode  during  steady 
state  broadcast  data  rate  operation. 

-  RBM  capability  to  acquire  and  continuously  receive  satellite 
downlink  in  less  than  3  minutes  after  initial  hardware  setup  (5 
minutes  for  Phase  II  threshold). 

-  RBM  capability  to  provide  a  minimum  downlink  availability  of 
97%  for  terminal  elevation  angles  greater  than  10°. 

4.  What  are  some  key  GBS  elements  for  successful  implementation? 

-  Primary  operational  control  over  what,  when,  and  to  whom 
information  is  disseminated  in  a  particular  AOR  (provided  by  the 
TIM). 

-  The  capability  for  “smart  push”  and  “user  pull,”  which  gives 
warfighters  the  right  information,  at  the  right  time,  and  in  the  right 
place. 

-  Oversight  of  the  SBM’s  management  of  the  broadcast  resources 
across  the  GBS  system  (responsibility  of  the  GBS  system 
operational  manager  (SOM),  which  is  the  Navy). 

-  The  use  of  organic  communications  to  accomplish  virtual  theater 
injection  when  a  TIP  is  not  available  or  is  not  an  effective  means  of 
injection  when  compared  to  the  PIP. 

-  The  minimization  of  additional  manning  for  the  PIPs,  TIPs,  SBMs 
and  possibly,  the  operation  and  maintenance  of  receive  suites.  No 
initial  training  requirements  are  required  for  the  SBMs  and  PIPs 
because  they  are  contractor  operated  and  maintained.  Training 
provisions  must  be  available  when  it  becomes  desirable  to 
transition  from  contractor  to  government  operation  and 
maintenance. 
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C.  GBS  JOINT  CONOPS 

The  GBS  Joint  CONOPS  describes  the  overall  system  architecture  and  CONOPS 
based  on  the  MNS,  the  ORD,  and  program  developments.  Due  to  the  evolution  of 
technology  and  concepts,  the  GBS  Joint  CONOPS  is  a  fluid,  dynamic  document.  It 
should  be  noted  that  the  GBS  Joint  CONOPS  is  the  responsibility  of  U.S.  Space 
Command.  Many  of  the  points  in  the  GBS  Joint  CONOPS  are  common  to  the  CINC 
CONOPS  drafts.  CINC  GBS  CONOPS  have  been  outlined  in  Appendix  D.  The  reader  is 
reminded  that  the  following  outline  contains  direct  content  from  the  GBS  Joint  CONOPS 
and  is  merely  organized  by  the  author  for  the  reader’s  reference. 

1 .  What  must  the  GBS  do? 

-  Act  as  an  extension  of  the  DISN  to  give  tactical  users  information 
at  high  broadcast  data  rates  -  through  "smart  push”  and  “user  pull" 
concepts. 

-  Distribute  data  products  simultaneously  and  quickly  by  using  a 
point-to-area  approach. 

-  Provide  high  quality  delivery  of  data  products  at  bit  error  rates  of 
10-'". 

-  Provide  video  requirements,  smart  push  data  requirements,  and 
user  pull  for  broadcast  schedules. 

2.  How  does  the  GBS  provide  information? 

Collects  the  deployed  user’s  "user  profile,"  which  consists  of  the 
type,  priority,  and  desired  delivery  times  of  required  information. 
The  TIM  validates  the  user  profile  against  CINC  policies  and 
priorities  for  the  use  of  infrastructure  resources  and  forwards  the 
profile  to  the  SBM.  The  TIM  can  then  coordinate  with  the  SBM 
and  the  information  producers  to  determine  broadcast  update 
requirements. 

-  Uses  “smart  push,”  which  takes  advantage  of  GBS’s  capability  to 
simultaneously  disseminate  information  to  many  users.  The 
primary  goal  of  smart  push  is  to  give  the  users  within  the  CINC’s 
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AOR  the  majority  of  their  predictable  information  needs. 

Evaluates  "smart  push"  products  to  ensure  their  priority, 
bandwidth,  and  spot  beam  requirements  fall  within  CINC  priorities 
and  allocated  resources. 

-  Uses  “user  pull,”  which  gives  authorized  users  in  the  theater  direct 
access  to  information  both  inside  and  outside  the  theater.  This 
approach  uses  existing  communications  means,  in  concert  with 
GBS,  to  create  a  virtual  two-way  network  for  interaction. 

-  Fills  "ad  hoc"  user  requests  on  an  as  available  basis 
(accommodated  dynamically,  based  on  user  and/or  mission 
priorities).  Feedback  from  the  user  pull  information  can  be  used  to 
better  predict  users'  needs  and  identify  products  for  the  smart  push 
part  of  the  broadcast. 

-  Uses  the  regional  broadcast  (via  PIP)  as  the  preferred  method  of 
broadcast  if  information  producers  have  sufficient  DII  connectivity 
to  the  SBM. 

Services  each  GBS  satellite  with  one  satellite  broadcast  manager 
and  one  primary  injection  point.  The  GBS  also  can  inject 
information  products  directly  from  the  theater. 

Provides  one-way  distribution  of  information. 

3.  What  are  some  key  GBS  requirements? 

-  The  maintenance  of  end  user  profiles  (description  of  user  receive 
configuration,  product  requirements,  location,  CINC  priorities, 
etc.)  at  the  SBM  in  order  to  enable  the  development  of  “smart 
push”  and  to  enable  access  control. 

The  capability  of  a  “virtual  injection”  from  theater  by  sending 
information  from  the  theater  to  the  SBM  via  an  alternative 
communications  link  within  the  DII. 

-  TIP  broadcasting  provides  direct  theater  injection  for  in-theater 
information  producers  lacking  DII  connectivity,  eliminates  the 
projected  delay  associated  with  transmitting  theater  generated 
information  to  the  PIP  for  broadcast  and  supports  high  priority 
operational  requirements.  Using  TIPs  also  increase  the 
commander’s  control  over  the  information  dissemination  process. 

-  Quality  feedback  reports  to  the  end  user  (for  users  with  receive 
suites  connected  to  other  communications  paths,  to  request  only 
missing  file  segments,  thus  significantly  reducing  the  GBS 
bandwidth  required  to  correct  errors). 


35 


4.  What  are  some  key  GBS  elements  for  successful  implementation? 

-  Adoption  of  new  technology  and  lessons  learned  (the  GBS  and 
BC2A  Program  Managers  ensure  that  IBS  and  BC2A  lessons 
learned  are  incorporated  into  the  GBS  program,  and  BADD  is 
attempting  to  develop  software  tools  and  applications  that  will 
facilitate  the  distribution  and  management  of  information). 

-  Utilization  of  a  variety  of  information  producers  (agencies,  fusion 
centers,  creators  of  value  added  products,  sensors  and  sensor 
ground  sites,  etc.).  Information  producers  desiring  to  transmit 
information  over  GBS  must  provide  the  following:  metadata 
headers  for  all  files,  a  catalog  of  specific  products  passed  to  the 
SBM,  and  updated  products  to  ensure  the  most  current  information 
is  available  to  users. 

-  Reliance  on  a  Theater  Information  Management  (TIM)  function, 
which  is  performed  at  the  CINC  level  (to  account  for  limitations  in 
user  equipment,  payload  configuration,  commander  in  chief 
(CINC)  priority  and  for  policy  development  and  operational 
control). 

-  CINC  organization  of  the  TIM  functions  within  their  AOR  (to 
provide  direction,  guidance,  and  policy  for  the  operation  of 
apportioned  GBS  resources). 

CINC  guidance  (including  who  is  authorized  access  to  GBS,  what 
information  is  releasable  to  coalition  partners,  what  kinds  of 
information  will  be  transmitted  over  GBS,  when  GBS  coverage  is 
needed  by  users,  and  a  rationale  for  GBS  employment  within  the 
AOR). 

CINC  priorities  (including  which  users  will  be  serviced  first,  which 
types  of  products  will  be  transmitted  first,  and  which  areas  will 
receive  coverage  first).  The  TIM  must  consider  priorities, 
equipment  configuration,  and  environmental  conditions  in  the 
decision  process. 

Simplicity  of  the  TIM  functionality  (to  minimize  manning  and 
training  impacts  to  the  CINCs).  The  six  TIM  functions  are 
directing  GBS  operations,  coordinating  the  broadcast  schedule, 
managing  the  apportioned  resources,  identifying  new  products, 
reviewing  and  validating  the  user  profile  data  base,  and  auditing 
user  pull.  The  TIM  must  balance  demand  with  available  resources 
and  work  with  users  to  meet  their  requirements. 

-  GBS  Resource  Allocation  Tool  (GRAT).  This  tool  will  allow 
information  managers  to  plan  their  allocation  of  GBS  broadcast 
resources  in  order  to  share  and  reallocate  available  bandwidth 
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among  various  users,  information  products,  multi-media  types 
(data,  video,  audio),  and  security  levels,  without  interruption  to  the 
broadcast. 

Successful  implementation  of  IDM  (vital  to  ensure  the  efficient 
flow  of  information  from  producers  to  users).  IDM  is  envisioned 
to  look  across  all  information  dissemination  in  DOD  and  develop 
the  capability  to  efficiently  route  information  from  source  to  user. 
Fulfillment  of  five  IDM  functions  (including  compiling, 
cataloging,  caching,  distributing,  and  receiving). 

Balanced  management  responsibilities  between  the  TIM  and  SBM 
(key  to  effective  use  of  the  GBS  communications  resources). 

SBM  traffic  analysis  (enabling  the  TIM  audit  function).  In 
addition,  the  GBS  system  is  capable  of  conducting  system 
performance  assessments  and  trending,  network  management,  and 
quality  control.  SBMs  use  this  information  to  conduct  traffic 
analysis  and  provide  TIMs  with  an  assessment  of  how  well 
information  is  flowing  over  their  allocated  resources. 

Consolidated  scheduling.  Due  to  limitations  in  the  design  of  the 
GBS  Phase  II  architecture,  there  will  always  be  more  CINCs  than 
satellite  hardware  resources,  therefore  the  cornerstone  to  integrated 
GBS  operations  is  the  combination  of  broadcast  information  into 
one  schedule. 

Fulfillment  of  eight  basic  SBM  functions.  These  functions  include 
building  a  schedule  and  program  guide,  coordinating  information 
products,  conducting  traffic  analysis,  constructing  and  transmitting 
the  broadcast  stream,  providing  for  data  protection,  technically 
controlling  the  GBS  broadcast,  remotely  controlling  the 
enabling/disabling  of  receive  suites,  and  establishing  and 
maintaining  the  user  profile  data  base. 

Dynamic  mix  of  “smart  push”  and  “user  pull.” 

Dissemination  of  broadcast  information  to  lower  echelon  vmits  via 
interface  with  existing  tactical  networks. 

User  profiles  (which  are  prepared  by  the  user  and  provided  to  the 
TIM  either  automatically  via  their  GBS  receive  suite  (fully 
connected  mode  only)  or  via  other  standard  means  of 
communication,  e.g.,  SIPRNET,  telephone,  etc.). 

Deliberate  planning  process  for  identification  of  the  majority  of  the 
smart  push  information  requirements.  Other  smart  push 
information  is  developed  during  the  initial  stages  of  the  conflict 
and  remain  relatively  constant  (with  some  fine-tuning)  for  the 
duration  of  hostilities. 

Predesignated  process  for  user  pull  requests  (to  go  directly  to  the 
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appropriate  information  producers).  The  communications  media 
could  be  SIPRNET,  N-level  (unclassified-but-sensitive)  Internet 
Protocol  Router  Network  (NIPRNET),  JWICS,  Fax,  GBS, 
telephone,  etc. 

As  already  mentioned,  this  chapter  provides  a  ready  reference  as  well  as  a 
foundation  to  understand  the  GBS  Concept  of  Operations.  Using  this  chapter  and 
Apendix  D  is  useful  in  any  attempt  to  design  and  implement  the  existing  or  future  Global 
Broadcast  Service  architecture.  The  MNS  and  ORD  are  included  in  the  work  in  order  to 
maintain  the  “big  picture”  on  what  the  GBS  should  actually  accomplish.  Frequent 
reference  to  these  documents  is  important  to  the  development  of  a  realistic  architecture. 
The  following  chapter  describes  the  author’s  attempt  in  designing  a  GBS  architecture 
model,  which  focuses  on  the  implementation  of  GBS  reach  back  (including  ADNS). 
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IV.  GBS  MODEL  DESIGN  AND  ANALYSIS 


A.  INTRODUCTION  TO  EXTEND 

1.  What  is  Extend? 

Extend,  Version  4  is  a  modeling  program  developed  by  Imagine  That! 
Incorporated.  This  simulation  software  supports  discrete  event,  continuous,  and 
combined  discrete  event/continuous  process  models  and  simulations.  Extend  can 
simulate  any  process  or  action;  however,  the  simplicity  of  its  building  blocks  dictates  that 
a  user  fully  understands  the  process  to  be  modeled.  In  actuality,  the  one  of  the  biggest 
limitations  to  an  Extend  model  is  the  user’s  imagination.  The  GBS  reach  back  model  is 
a  discrete  process  model,  but  does  include  some  continuous  process  blocks. 

The  libraries  in  Extend  contain  building  blocks  that  perform  various  functions, 
which  represent  basic  processes  or  actions.  Appendix  F  provides  function  descriptions 
of  common  Extend  blocks  that  were  used  in  the  GBS  reach  back  model.  The  block  icons 
are  connected  in  a  logical  sequence  representative  of  the  process  or  action  to  be 
simulated.  Double  clicking  on  the  icon  displays  a  dialog  box  for  the  user  to  provide 
inputs.  Example  inputs  include  the  maximum  size  for  a  queue,  an  equation,  or  a  selection 
of  a  probability  distribution.  Once  the  blocks  are  made,  coimected  and  parameters 
inputted,  a  simulation  run  can  be  conducted.  While  building  the  model,  tools  such  as 
timers  and  plotters  can  be  strategically  located  to  collect  data  and  evaluate  model 
performance.  In  addition,  attributes  can  be  assigned  to  the  discrete  items  as  they  pass 
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through  certain  blocks.  This  function  provides  the  ability  to  place  time  stamps 
throughout  sections  of  the  model  to  evaluate  timeliness.  More  detailed  explanations  of 
Extend  can  be  found  in  Rieffer  (pp  81-91)  or  the  Extend  Users  Manual.  In  addition. 
Appendix  F  includes  definitions  of  selected  blocks  used  in  the  reach  back  model. 

2.  Limitations  of  Extend 

Extend  can  lock  up  a  PC,  even  a  400  megahertz  (MHz),  64  megabyte-RAM 
(random  access  memory)  machine,  if  the  model  gets  too  large  (greater  than  approximately 
50  megabytes  [Mb]).  Lock  up  was  common  when  trying  to  copy  for  testing  and 
debugging  and  when  the  PC  tried  to  auto  save  the  model.  A  user  should  decide  how 
granular  and  detailed  the  model  should  be  prior  to  modeling  with  Extend.  The  50  Mb- 
GBS  reach  back  model  did  not  inhibit  Extend,  but  did  cause  significant  delays  in 
programming  and  data  collection  (depending  on  the  number  of  time  steps  simulated).  For 
instance,  hours  of  design  time  were  lost  due  to  the  programming  problems  experienced 
when  the  model  size  approached  50  Mb.  Likewise,  to  simulate  one  hundred  seconds,  one 
simulation  run  would  take  over  one  hour.  In  addition  opening  and  saving  the  model 
exceeds  five  minutes  when  working  with  greater  than  50  Mb-sized  models. 

Hence,  due  the  complexity  of  the  reach  back  architecture  and  the  observed 
degraded  performance,  the  author  believes  the  GBS  model  approaches  the  upper  bound  of 
Extend  limitations.  This  limitation  caused  the  author  to  simplify  the  model  significantly 
(after  the  reach  back  channel  transmissions)  and  also  caused  a  less  rigorous  data  analysis 
function  to  be  implemented.  Thus,  any  improvements  to  the  GBS  Extend  model  have  to 
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be  done  in  a  piecemeal  fashion  in  order  to  avoid  program  memory  limitations.  More 
granular  studies  (any  model  requiring  greater  than  50  Mb)  should  be  done  with  more 
powerful  communications  modeling  tools  such  as  OPNET  Radio  Modeler  (by  MILS)  and 
COMNET  III  (by  CACI Products,  Inc.).  This  limitation  does  not  mean  Extend  cannot  be 
used  for  very  granular  studies.  Detailed  studies  may  still  be  done  using  Extend,  but  the 
system  has  to  be  small.  Some  specific  limitations  of  Extend  are  listed  in  Table  1. 


Blocks  in  a  model 

2  billion 

Output  connectors  in  a  model  (nodes) 

2  billion 

Connectors  per  block 

255 

Dialog  items  in  a  block 

1024 

Blocks  in  a  library 

200 

Libraries  open  at  one  time 

30 

Steps  in  a  simulation  run 

2  billion 

#  of  attributes  for  discrete  event  item 

100 

Number  of  simulations  in  a  multiple  run 

32K 

Table  1 .  Example  Extend  Limitations  [EXTEND] 


B.  METHODOLOGY 

The  design  portion  of  this  project  was  conducted  in  six  steps:  modeling  tool 
selection,  network  characterization,  logical  model  development,  simulation  and  data 
collection,  data  analysis,  and  conclusions  (summary  of  findings).  The  first  five  steps  are 
discussed  in  this  chapter  and  the  summary  of  findings  are  presented  in  the  next  chapter. 
Further  model  application  (specifically  for  GBS  IDM  process  development)  and 
validation  is  left  as  an  area  for  further  study. 

1.  Modeling  Tool  Selection 

There  are  numerous  computer-based  modeling  and  simulation  tools  available  to 
conduct  network  modeling.  Three  tools  (COMNET  III,  OPNET  and  Extend)  available  at 
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the  research  site  (NPS)  were  considered  for  use  by  the  author.  The  author  chose  to  use 
Extend,  Version  4,  for  reasons  discussed  below. 

Extend  is  an  advanced  simulation  tool  designed  for  decision  support.  Although 
the  program  is  not  designed  specifically  for  communications  modeling,  the  basic  blocks 
and  the  user-friendly  GUI  (graphic  user  interface)  environment  allow  for  fast 
development  of  models.  Likewise,  the  ability  to  build  any  process  firom  basic  blocks 
make  Extend  ideal  for  analyzing  high-level  models  in  which  hardware  and  data  do  not 
exist.  Given  that  GBS  is  relatively  new  and  the  project  involved  time  constraints,  the 
selection  of  Extend  became  a  logical  choice.  Additional  detailed  models  can  be  derived 
from  this  project’s  model  to  conduct  more  thorough  analysis.  It  should  be  noted, 
however,  to  be  useful  for  the  TIM,  a  relatively  inexpensive  COTS  program  like  Extend 
may  be  best  to  understand  the  GBS  data  flow  (given  time  constraints  and  the  need  to  look 
at  information  flow  at  a  high  level). 

The  model  in  this  project  was  tailored  to  look  at  the  latency  of  message  request- 
to-product  receipt  as  traffic  loading  increases.  In  addition,  simulation  of  the  model 
provides  the  ability  to  assess  the  limits  each  reach  back  channel  places  on  user 
throughput.  A  study  on  throughput  is  left  as  an  area  for  future  study. 

The  GBS  model  is  also  characterized  by  himdreds  of  user  inputs  (which  can  be 
organized  in  a  single  Extend  notebook).  Inputs  such  as  message  rate,  message  attributes 
(i.e.,  sizes,  classification,  source/user  priority,  port  priority,  node  identification,  unit 
identification),  maximum  transmission  units,  overhead,  data  rate,  segmentation  and 


42 


reassembly  rate  (SAR),  bandwidth,  communication  system  status,  and  equation 
algorithms  (i.e.,  congestion  control  cost  for  ADNS)  are  just  a  few  examples  of  how  the 
model  can  be  tailored.  If  one  realizes  that  the  inputs  just  described  only  affect  one  node 
(of  six)  on  one  of  thirteen  platforms,  then  it  can  be  seen  that  the  model  variations  are 
endless.  Appendix  G  lists  some  of  these  inputs.  As  a  result,  the  model  can  be  used  to 
conduct  focused  studies  based  on  specific  reach  back  channels,  users,  or  other  groupings 
of  interest.  Time  constraints  of  this  project  limit  analysis  to  basic  measures  of  timeliness. 

Once  the  model  is  built,  verification  and  debugging  can  be  done  to  observe 

performance.  A  very  useful  Extend  functionality  is  the  ability  to  animate  simulations. 

1 

Physically  seeing  items  move  through  the  model  is  helpful  in  troubleshooting.  However, 
using  the  animation  takes  up  a  significant  amoimt  of  system  memory  and  significantly 
increases  simulation  time.  Once  debugged,  the  data  collection  can  begin.  First,  however, 
it  is  helpful  for  users  to  identify  what  is  to  be  measured.  As  already  mentioned, 
throughput  and  timeliness  are  two  important  measures  of  performance  that  can  be  easily 
studied  with  the  incorporation  of  plotters,  timers  and  time  stamp  attributes.  Finally, 
simulation  runs  are  conducted  to  collect,  tabulate  and  present  data  in  a  fashion  easily 
interpreted. 

2.  Network  Characterization  and  Model  CONOPS  Description 

Characterization:  The  three  scenarios  originally  envisioned  included  a  carrier 
battle  group  (CVBG)  in  transit,  an  amphibious  readiness  group/marine  expeditionary  unit 
(ARG/MEU)  in  a  small  scale  contingency  (SSC)  operation,  and  a  joint  coalition  force 
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involved  in  a  major  theater  war  (MTW).  These  three  scenarios  were  chosen  because  they 
are  indicative  of  normal  and  heavy  traffic  load  conditions  and  provided  the  opportunity  to 
assess  various  reach  back  channels  on  a  variety  of  users.  Nevertheless,  due  to  the  time 
constraints,  the  enormous  complexity  of  a  MTW,  and  the  complexity  of  the  GBS 
configurations,  only  one  of  the  three  scenarios  was  built.  The  same  variation  in  traffic 
loading  can  be  studied  by  taking  one  model  and  varying  the  message  rate  inputs. 

DISA  D82  is  plarming  to  build  upon  their  recent  modeling  assessment  of  the 
PACOM  DISN  (using  COMNET  III).  They  plan  to  analyze  the  DISN  again  with  GBS 
implemented.  [Berry]  Additionally,  follow-on  NPS  work  will  research  integration 
solutions  for  the  “stove-piped”  Service  SATCOM-DISN  entry  sites. 

As  discussed,  the  modeled  network  in  this  project  is  a  highly  asymmetric  network. 
The  network  uses  the  GBS  as  the  primary  system  for  information  delivery  and  seven 
existing  or  plaimed  (near  term)  military  and  commercial  communications  systems  as  back 
chaimels.  Obviously,  the  common  communications  system  for  all  users  in  the  model  is 
the  GBS.  However,  each  user  has  its  own  mixture  of  back  channels. 

The  GBS  users  are  various  Naval  forces  in  an  imaginary  CVBG.  The  seven  back 
chaimels  modeled  are  SHF,  commercial  wideband  (Challenge  Athena  and  Inmarsat  B) 
and  narrowband  (Iridium),  HF,  UHF  DAMA  (demand  assigned  multiple  access),  and 
EHF  LDR  (low  data  rate).  Detailed  discussions  of  the  reach  back  channels  and  model 
assumptions  are  provided  later  in  Section  3b  (Methodology).  Some  broad  model 
characteristics  and  assumptions  are  provided  in  Table  2. 
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Characteristic 

Assumption 

Time  Frame 

Around  Year  2000 

Location 

Western  Pacific  (within  500nm  of  nearest  HF  station) 

Units 

One  CVBG 

CVBG  Composition 

1  CVN,  2  CGs,  2  DDGs,  2  DDs,  2  FFGs,  3  SSNs,  1  AOE 

Message  Rates 

See  Appendix  I 

Ship  Subnets 

Fast  Ethernet 

Ship  Backbones 

CVs,  CGs,  DDGs  &  SSNs  with  ATM;  other  units  with  FDDI 

Reach  Back  Channels 

Fully  Connected  Users;  see  Appendix  H  for  unit  capabilities 

GBS  Channel  Allocation 

15  Mbps  for  all  IP  (variable)  data 

Table  2.  Summary  of  Model  Assumptions 


As  indicated  in  Table  2,  each  of  the  thirteen  ships  in  the  CVBG  GBS  reach  back 
model  are  built  with  back  channel  capabilities  representative  (though  optimistic)  of  that 
unit  type  in  the  year  2000  (see  Appendix  G,  FYDP  Future  Bandwidth).  Appendix  C 
(Topology  of  Users)  in  the  [IBS  ORD]  was  also  used  to  identify  unit  RB  capabilities. 
The  CVBG  composition  and  bandwidth  allocations  are  derived  from  the  Navy  FRD 
(Functional  Requirements  Database)  and  ERDB  (Emerging  Requirements  Data  Base). 
Appendix  H  indicates  the  force  composition  for  the  models  and  for  Fiscal  Year  Defense 
Plan  (FYDP)  and  2010.  Appendix  H  also  provides  the  bandwidth  assignments  for  the. 
models  and  the  requirements  for  FY98/99  implementation,  FYDP  (2003),  and  2010. 
Rather  than  use  numbers  to  match  the  estimated  unit  bandwidth  requirements,  the  author 
incorporates  unit  allocations  based  on  what  can  be  expected  presently  and  in  the  near 
future.  One  significant  model  drawback  is  characterization  of  the  bandwidth  allocations 
to  fit  actual  availability  of  the  channels  for  GBS  reach  back  traffic.  This  deficiency  can 
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be  overcome  by  increasing  the  message  rates  of  the  subnet  users  (nodes)  that  do  not 
initiate  return  products.  These  users  are  implemented  into  the  model  to  provide  traffic 
loading  in  addition  to  the  reach  back  requests. 

As  already  mentioned,  the  model  takes  into  account  many  factors  that  can  be 
varied.  The  reader  is  reminded  that  the  GBS  Extend  model  is  a  discrete  event  model  and 
as  such,  the  approach  to  modeling  the  GBS  reach  back  architecture  is  to  simplify  the 
system  into  object-oriented  sections  starting  from  a  user  on  a  ship.  Divisions  quickly 
became  apparent.  The  users  themselves  are  complex  and  it  was  decided  to  incorporate 
them  into  a  fast  Ethernet  (using  CSMA/CD,  Carrier  Sense  Multiple  Access  with  Collision 
Detection)  subnet,  which  aggregated  the  entire  ship’s  network  to  this  one  subnet  (with  six 
end  users).  The  subnet  then  interfaced  with  a  simplified  ATM  or  FDDI  backbone.  The 
ATM  and  FDDI  backbone  blocks  are  not  fully  developed,  but  incorporate  delays  based 
on  MTU,  SAR  and  capacity  inputs.  For  additional  simplification,  the  model  did  not 
incorporate  real  time  voice  and  video.  One  can  easily  integrate  voice  and  video  (e.g., 
VTC)  users  into  the  ship’s  backbone.  Previous  NPS  research  incorporated  VTC  in  an  IT- 
21  model  (ATM  backbone)  using  both  Extend  and  OPNET  (see  Rieffer).  The  GBS 
Extend  model  simplifications  in  this  project  helped  reduce  the  development  requirements 
and  also  alleviated  the  processing  demand  on  the  computer  hosting  the  simulation.  More 
detailed  user  characterization  is  discussed  in  the  section  on  logical  model  development. 

Model  CONOPS  Description:  A  top  level  view  of  the  model  is  provided  in 
Figure  9. 
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Figxure  9.  GBS  Reach  Back  Top  Level  View 
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General  model  flow  goes  from  left  to  right.  Once  items  reach  the  right  side  of  the 
model,  they  are  transported  back  to  the  original  users  (via  the  forward  communications 
channel,  normally  GBS).  Basic  flow  goes  from  (1)  one  of  thirteen  ships  (2)  to  one  of 
seven  back  channel  systems  (via  each  ship’s  ADNS)  (3)  to  the  gateways  (4)  to  the  DISN 
(5)  to  the  information  producers  (6)  back  to  the  DISN  (7)  to  the  NCTAMS/TIM  ADNS 
(8)  to  the  GBS  SBM  (9)  to  the  GBS  satellite  (10)  and  back  to  the  originating  ship’s  RBM 
(11).  The  following  paragraph  provides  further  explanation  of  the  model  CONORS  by 
stepping  through  an  example  user  pull  operation.  It  should  be  noted  that  the  actual  GBS 
flow  goes  from  the  DISN  to  the  SBM/TIM  and  then  to  the  information  producers  (to 
return  back  to  the  SBM).  The  actual  information  flow  was  not  developed  in  order  to 
simplify  the  model.  Nevertheless,  the  ability  for  users  to  commimicate  directly  with 
information  producers  gives  them  better  access.  An  in  depth  discussion  on  the  issue  of 
user  access  and  TIM  control  is  beyond  the  scope  of  this  document,  but  is  briefly 
addressed  in  the  Section  IV-B3-C  (Role  of  the  TIM). 

The  following  description  describes  an  example  user  pull  flow  for  the  model.  A 
CVN  end  user  on  a  ship  sends  a  WWW  browsing  (HTTP)  request  for  a  document  on  the 
SIPRNET.  The  request  message  travels  outside  the  six-node  subnet  (fast  Ethernet)  to  the 
ship's  ATM  backbone  to  the  ADNS  router.  The  CVN's  ADNS  senses  the  channel  that  has 
the  least  congestion  cost  (based  dynamically  on  system  bandwidth,  imit  bandwidth  and 
current  system  and  imit  use)  and  sends  the  message  packets  via  that  route.  A  message’s 
packets  may  travel  on  different  paths  to  get  to  its  destination  because  ADNS  senses 
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channel  availability  for  each  packet  and  not  for  each  message.  The  packets  will  be 
delayed  based  on  transmission,  propagation  and  processing  characteristics  associated  with 
the  specific  reach  back  channel.  At  the  entry  site  (i.e.,  NCTAMS),  the  request  message 
packets  are  further  routed  on  to  the  SIPRNET/DISN  (ATM)  for  delivery  to  the 
information  producer.  Upon  receiving  the  request,  the  information  server  sends  the 
requested  dociiment  to  the  Theater  Information  Management  (TIM).  The  TIM  sees  all 
information  destined  for  the  SBM  and  audits  the  flow.  After  TIM  validation,  the 
requested  product  is  routed  (via  ADNS)  to  the  GBS  Satellite  Broadcast  Manager  (SBM) 
for  broadcast  scheduling.  The  TIM  (recommended  to  be  co-located  at  a  communications 
hub  such  as  NCTAMS)  also  incorporates  an  ADNS  switch  that  decides  what  forward 
channel  to  send  the  document.  If  GBS  (which  normally  will  be  the  case)  is  the  best 
distribution  path,  the  document  will  be  sent  to  the  SBM  to  wait  in  a  queue  imtil  placed  on 
the  Secret  IP  broadcast  channel.  Once  selected  for  GBS  broadcast,  the  document  IP 
packets  are  multiplexed  into  the  DVB  (digital  video  broadcast)  waveform  where  it  travels 
the  GBS  space  segment.  During  the  GBS  space  segment  the  packets  experience  delay 
due  to  transmission,  propagation  and  satellite  processing.  The  CVN  receives  the 
broadcast  via  the  Secret  Receive  Broadcast  Manager  (RBM)  PC.  The  document  packets 
are  then  routed  from  the  Secret  RBM  to  the  ship's  ATM  backbone.  From  the  backbone,  it 
goes  back  to  the  original  fast  Ethernet  hub.  Normally,  the  hub  would  send  the  packets  to 
the  originating  node,  but  the  model  sends  all  received  packets  to  a  data  analysis  node  for 
easier  data  collection. 


49 


Although  not  modeled,  an  example  smart  (TIM)  push  flow  is  described  for  the 
reader’s  reference  and  future  incorporation  into  the  model.  The  TIM  approves  an  image 
produced  by  NIMA  (National  Imagery  and  Mapping  Agency)  to  be  broadcast  by  GBS  on 
the  Secret  IP  data  channel.  The  approval  is  based  on  user  requirements  and  CINC 
priorities.  The  approved  broadcast  image  is  scheduled  to  be  transmitted  by  the  SBM. 
The  image  waits  in  a  queiie  until  it  is  placed  on  the  Secret  IP  broadcast  channel.  Once 
placed  on  the  GBS  broadcast,  the  image  IP  packets  are  multiplexed  into  the  DVB 
waveform  where  it  travels  the  GBS  space  segment.  During  the  GBS  space  segment  the 
packets  experience  delay  due  to  transmission,  propagation  and  satellite  processing.  The 
CVN  receives  the  broadcast  via  the  Secret  RBM  PC,  assuming  the  RBM  has  the  filter  to 
accept  the  image  (and  the  current  user’s  filter  is  stored  at  the  SBM).  The  image  packets 
are  then  routed  from  the  Secret  RBM  to  the  ship's  ATM  backbone.  From  the  backbone, 
the  image  packets  go  to  the  end  users  (via  the  Ethernet  subnet)  that  are  filtered  to  accept 
the  image.  It  was  the  author’s  intention  to  provide  the  smart  push  path  flow  into  the 
model.  Due  to  model  limitations  and  time  constraints  the  smart  push  development  is  left 
to  the  researcher  that  is  interested  in  studying  the  GBS  IDM  process  and  seeks  to  answer 
the  question  of  “What  is  the  right  mix  of  smart  push  and  user  pull?”  The  modeled  ships 
are  designed,  however,  to  receive  push  products. 

3.  Logical  Model  Development 

Models  are  first  sketched  on  paper  from  the  highest  level  view.  Verbal 
descriptions  of  the  sketched  nodes  and  discrete  event  item  flow  are  also  put  on  paper. 
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Once  comfortable  with  the  flow  of  the  model,  the  model  is  built  firom  left  to  right. 
Consequently,  the  user  transmit  portion  on  the  left  also  becomes  the  receive  portion  once 
a  packet  has  reached  the  right  end  of  the  model.  At  the  right  end,  the  packets  are 
“thrown”  back  to  the  users  on  the  left  via  the  GBS  satellite,  a  traffic  sorter  block  and 
“named”  connectors. 

As  described  in  the  model  CONOPS,  the  user  in  a  ship  generates  request 
messages,  which  are  transmitted  to  an  entry  site  via  ADNS  and  the  back  channel  system. 
The  entry  site  forwards  the  requests  to  the  information  producers.  Upon  receiving 
requests,  the  producers  send  information  products  to  the  TIM.  The  TIM  passes  the 
information  (once  validated)  to  the  SBM.  The  SBM  processes  the  products  and  transmits 
them  to  the  original  user  via  the  GBS.  Another  ADNS  switch  is  incorporated  with  the 
TIM  to  give  the  product  the  ability  to  go  back  via  the  back  channel  if  it  is  less  “costly” 
than  the  GBS  (e.g.,  the  weather  is  bad  and  GBS  service  is  severely  degraded).  More 
detailed  discussion  of  users,  reach  back  channels,  TIM,  and  the  SBM  are  provided  in  the 
following  sections. 

a.  Identifying  the  Users  and  Their  Requirements 

Users  must  be  able  to  interact  with  the  GBS.  The  model  allows  users  to 
request  information  much  like  in  the  real  world  when  a  user  must  query  for  additional 
information  on  a  reported  entity  or  archived  database.  An  alternative  approach  to  the 
user’s  query  is  the  smart  pushing  of  pre-determined  data.  In  the  GBS  system,  to 
effectively  implement  smart  push,  the  users  must  forward  their  information  requirements 
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to  the  CINC  TIM/SBM  in  order  to  activate  and  set  the  user’s  filter  (by  geography  or 
activity)  at  the  SBM.  As  already  mentioned,  this  project’s  model  provides  the  means  for 
information  delivery  via  the  former  approach  and  does  not  model  smart  push. 

There  are  two  types  of  tactical  users:  small  (highly  mobile)  or  large  (fixed 
or  mobile).  [IBS]  The  CVN  in  the  model  can  be  considered  as  large  and  mobile  while  all 
other  ships  are  small  and  highly  mobile.  In  addition,  end  users  on  each  ship  are  assigned 
priorities  which  correspond  with  the  SATCOM  priorities  listed  in  CJCSI  Draft  6250.01. 
Note  that  Priority  Zero  is  not  used  unless  in  an  emergency.  Table  3  indicates  the  standard 
composition  of  priorities  assigned  to  each  message.  Appendix  I  further  defines  the 
SATCOM  priorities.  It  should  be  noted  that  these  priorities  in  combination  with  the 
“NodelD”  attribute  are  equated  to  the  user’s  IP  address  (or  source).  This  prioritization 
becomes  important  for  datagram  routing  by  ADNS.  The  user  priority  has  precedence 
over  all  other  priorities  (e.g.,  port  priority). 

As  already  mentioned,  the  Ethernet  message  generator  in  Figure  10  takes 
message  rate  inputs  (messages  per  hour)  to  produce  items  (messages)  with  an  exponential 
arrival  interval  (Poisson  arrival  rate).  The  unit  default  message  rates  are  derived  from  the 
predicted  numbers  of  computers  for  IT-21  implementation  (see  Figure  11). 

The  total  default  message  rates  in  messages  per  hour  are  12000  for  Email, 
2200  for  message  traffic,  22000  for  HTTP,  2200  for  FTP,  1200  for  imagery  requests,  and 
1200  for  tactical  requests.  These  totals  are  divided  and  apportioned  to  the  ships  based  on 
the  total  number  of  computers  per  unit  relative  to  other  units. 
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Appendix  G  provides  the  message  rate  inputs  for  each  unit.  In  the 
assignment  of  attributes  block,  message  sizes  are  generated  using  a  normally  distributed 
random  number  generator  in  which  the  mean  and  standard  deviation  is  determined  by 
user  inputs.  Appendix  G  also  provides  the  message  sizes  and  deviations  for  each  unit. 
Likewise,  each  item  generated  is  given  other  attributes  to  be  later  used  in  the  model  (e.g., 
the  ADNS  section).  These  attributes  include  priority  of  user  (see  Table  3),  classification 
(see  Table  4),  priority  of  application  (see  Table  5)  and  product  request  (see  Table  6). 
Other  attributes  assigned  in  the  Ethernet  generator  include  collisions  and  node 
identification.  The  number  of  collisions  is  set  to  zero  initially.  If  the  packet  experiences 
a  collision  in  the  Ethernet  hub,  the  number  of  collisions  is  incremented  by  one.  The 
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packet  is  then  sent  back  to  the  Ethernet  generator  catch  block  for  retransmission  (after  a 


back-off  period  determined  from  the  number  of  collisions  the  packet  has  experienced  and 


the  current  use  of  the  network  by  other  nodes).  This  process  is  consistent  with  carrier 


sense  multiple  access/collision  detection  (CSMA/CD)  in  Ethernet  networks.  [Stallings] 
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Figure  11.  IT-21  Unit  Capabilities  [Mayo] 


Value 

Probability 

0  Assigned  only  by  NCA/Joint  Staff  for  emergent  contingencies 

0 

1  Strategic  Order  (Essential  to  National  Survival) 

.05 

2  Warfighting  Requirements 

.05 

3  Essential  Support 

.25 

4  Training 

.40 

5  VIP  Support 

.10 

6  RDT&E  (including  quality  of  life  initiatives) 

.10 

7  Miscellaneous 

.05 

Table  3.  Default  User  Priority  Assignments 
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Value 

Probability 

1  (Top  Secret) 

.20 

2  (Secret) 

.40 

3  (Unclassified) 

.40 

Table  4.  Default  Message  Classification  Assignments 


Value 

Probability 

1  (equivalent  to  Higher  Applications) 

.40 

2  (equivalent  to  FTP) 

.20 

3  (equivalent  to  HTTP) 

.20 

4  (equivalent  to  Email) 

.20 

Table  5.  Default  Port  Priority  Assignments 


Item  Number 

Product 

Mean  Size 

1 

Tactical  Data 

8  kbits  (std  dev  1 .5  kbits) 

2  " 

Imagery 

90  Mbits  (std  dev  ISMbits) 

3 

Word  Docs/.ppt  briefs 

60Mbits  (std  dev  lOMbits) 

4 

Video/Audio 

120  Mbits  (std  dev  20Mbits) 

5 

FTP 

120  kbits  (std  dev  20kbits) 

6 

HTTP 

280  kbits  (std  dev  60kbits) 

7 

Message  Traffic 

60  kbits  (std  dev  lOkbits) 

8 

Email 

12  kbits  (std  dev  2.5kbits) 

Table  6.  Default  Product  Request  Assignments 


The  messages  are  broken  up  (if  required)  based  on  the  inputs  for  MTU 
(maximum  transmission  unit)  and  overhead.  Thus,,  the  message  item  becomes  a  packet 
item  or  a  number  of  packet  items.  Another  attribute  is  assigned  to  signify  the  packet  size. 

The  default  MTU  and  overhead  inputs  for  the  model  are  1500  bytes 
(12000  bits)  and  20  bytes  (160  bits),  respectively.  Hence,  the  Ethernet  generator  breaks 
messages  into  1500-byte  packets  or  less  with  an  overhead  of  20  bytes.  The  IP  header  is 
included  within  the  overhead.  The  MTU  and  IP  overhead  inputs  can  be  changed  in  the 
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appropriate  constant  block  dialog  box  or  the  Extend  notebook.  Different  inputs  may  be 
required  to  reflect  individual  systems  and  protocols.The  model  assumes  TCP/IP 
communication,  hence  20  bytes  of  TCP  overhead  (including  header)  is  added  to  the 
packet  size.  Finally,  the  model  generator  delays  the  packets  based  on  the  input  user  data 
rate  (default  input  is  100  Mbps),  which  affects  the  time  it  takes  for  the  packet  to  be 
transmitted.  The  six  message  generators  (Email,  Message  Traffic,  HTTP,  FTP,  Product 
Requests,  and  Tactical  Order  Wire)  sent  packets  into  the  subnet  shown  in  Figure  12. 


Figure  12.  Aggregated  Shipboard  Subnet  within  an  ATM  LAN 
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m 


Figure  13.  Ethernet  Hub 


Figure  13  above  shows  the  CSMA/CD  structure  of  the  Ethernet  subnet’s 
hub.  The  reader  is  referred  to  Stallings  and  Stevens  for  a  detailed  discussion  of 
CSMA/CD.  From  the  subnet,  packets  enter  the  asynchronous  transfer  mode  (ATM) 
backbone  and  experience  cell  conversion  and  ATM  delay.  From  the  ATM  backbone,  the 
packets  enter  the  ship’s  ADNS  (which  is  handling  IP  packets  vice  ATM  cells).  Once 
products  return  based  on  the  generated  requests,  they  enter  via  the  GBS  RBM  or  the  two- 
way  block  (which  simulates  returning  via  the  ship’s  ADNS  CAPs).  The  products 


subsequently  enter  the  ATM  backbone  and  the  Ethernet  subnet.  After  the  subnet  the 
packets  are  sent  to  the  data  analysis  block.  In  reality,  the  packets  are  sent  back  to  the  six 
generators,  but  a  single  block  was  used  to  receive  all  packets  in  order  to  simplify  data 
analysis.  The  data  analysis  block  is  explained  later  in  this  chapter  in  Section  5. 

b.  Identifying  Model  Back  Channels  and  Traffic  Routing  Scheme 

Specific  commercial  wideband  channels  modeled  include  Challenge 
Athena  and  Inmarsat  B.  Teledesic  was  not  modeled,  but  can  be  added  as  another  channel 
or  as  a  replacement  to  Challenge  Athena.  Likewise,  the  model  uses  Iridium  as  the 
commercial  narrowband  back  channel,  but  another  narrow  band  MSS  (Mobile  Satellite 
System)  could  also  be  used  (e.g.,  Globalstar  and  ICO).  Figure  14  illustrates  the 
SATCOM  satellites  possibly  available  to  units  in  the  year  2003. 


Figure  14.  FYDP  SATCOM  Constellations  [Boyd] 
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The  following  subsections  discuss  the  reach  back  channel  model 
assumptions  and  system  description.  Commercial  systems  other  than  Inmarsat  B  are  not 
described  in  depth  and  the  reader  is  referred  to  the  research  of  others  and  the  official 
documents  of  the  commercial  companies  themselves.  The  discussions  are  focused  to 
address  the  five  SATCOM  key  performance  parameters  (KPPs)  as  mentioned  in  the 
Advanced  Satellite  Communications  Capstone  Requirement  Document.  The  KPPs 
include  coverage,  capacity,  protection,  access  and  control,  and  interoperability. 
[SPACECOM]  In  addition,  the  reader  is  referred  to  [Powers]  for  an  in  depth  assessment 
of  using  commercial  systems  for  military  communications.  Likewise,  a  study  on 
Teledesic  for  military  use  can  be  found  in  [Wickline]. 

1)  Super  High  Frequency 

Model:  Assumptions  include  the  use  of  DSCS  III;  a  40 W  channel  for 
forces  in  each  scenario;  1.9Mbps  total  SHF  system  capacity  (divided  among  a  maximum 
of  14  ships  using  TDMA);  afloat  users  equipped  vvdth  ANAVSC-6  variant  terminals;  SHF 
availability  to  the  CVN  via  a  7  ft  antenna;  to  CGs  and  DDGs  via  a  4  ft  antenna;  to  SSNs 
via  16  inch  antennas.  CVN  nominal  throughput  is  768  kbps;  CG/DDG  throughput  is  256 
kbps  and  SSN  throughput  is  64  kbps. 

System  Description:  SHF  systems  support  worldwide  users  ashore  and 
afloat.  The  DSCS  III  satellite  constellation  consists  of  five  satellites  with  six  independent 
transponder  channels  each.  The  DSCS  III  SLEP  program  will  extend  naval 
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communications  from  the  sharing  of  only  one  50W  channel  (currently  channel  1)  to 
having  one  dedicated  SOW  channel  and  sharing  another  (channel  3  and  1  respectively). 
Each  spacecraft  has  two  19  element  (single  beam)  antennas  and  one  33”  diameter 
steerable  parabolic  downlink  antenna;  there  are  also  2  downlink  earth  coverage  horns. 
Shore  SHF  uplinks/downlinks  for  the  Navy  consists  of  GSC-39/52  and  FSC-78  medium 
and  heavy  earth  terminals  located  at  the  three  NCTAMS  worldwide.  The  AN/WSC-6  (V) 
1-6  is  the  standard  shipboard  terminal  in  4  and  7-foot  diameters.  For  GMF  missions  the 
AN/TSC-93B  is  the  standard  SHF  SATCOM  terminal  with  an  8-foot  diameter  dish. 
[NTP2] 

SHF  SATCOM  is  a  joint  asset  whose  wide  bandwidth  and  high  data  rate 
characteristics  provide  the  additional  satellite  capacity  required  by  all  of  the  Services. 
The  Navy’s  early  access  supported  afloat  Numbered  Fleet  Commanders  using  the  jam- 
resistant  (spread-spectrum/code-division  multiple  access  [SSM A/CDMA])  mode  of 
operation  that  provides  a  4.8  kpbs  maximum  aggregate,  full-duplex  capability,  and 
Surveillance  Towed  Array  Sensor  System  (SURTASS)  asymmetrical  frequency-division 
multiple  access  (FDMA)  mode  of  operation.  The  afloat  Numbered  Fleet  Commander 
capability  was  limited  to  a  few  medium  data  rate  (1.2-2. 4  kbps)  circuits  with  most  of  the 
C4I  direct  connectivity  provided  via  low  data  rate  (LDR)  channels.  Navy  C4I 
requirements  increased  significantly  during  Operation  Desert  Shield/Storm,  which 
saturated  all  available  satellite  assets.  The  bandwidth  and  high  data  rate  characteristics  of 
DSCS/SHF  SATCOM  emerged  as  the  best  solution  to  provide  additional  satellite 
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capacity.  Current  Navy  SHF  SATCOM  networks  provide  afloat  units  with  high  capacity 
telecommunications  trunks  that  are  terminated  at  NCTAMS  STEP  facilities. 

Coverage:  DSCS  SHF  worldwide  coverage  extends  from  70°  N  to  70°  S. 
There  are  two  series  of  DSCS  III  satellites;  A-series  and  B-series.  A-series  are  the  first- 
generation  DSCS  III  satellites.  The  newer  B-series  have  received  upgrades  to  various 
support  subsystems  and  the  commimications  system. 


Satellite  Ocean  Area 

DSCS  in  Satellite  Model 

Longitude  (Degrees) 

East  Pacific  Primary 

B-14 

135W 

East  Pacific  Reserve 

A-1 

130W 

West  Atlantic  Primary 

B-7 

52.5W 

West  Atlantic  Reserve 

B-4 

42.5W 

East  Atlantic  Primary 

B-12 

12W 

Indian  Ocean  Primary 

B-10 

60E 

Indian  Ocean  Reserve 

A-2 

57E 

West  Pacific  Primary 

B-9 

175E 

West  Pacific  Reserve 

B-5 

180E 

Table  7.  DSCS  III  Satellite  Positions  [FAS] 


The  commimications  subsystem  may  simultaneously  employ  veirious 
modes  of  transmission  and  reception:  full  Earth  coverage,  area  coverage,  and  narrow 
coverage.  Using  multiple  beam  antenna  (MBA),  the  capability  exists  to  provide  -narrow 
coverage,  area  coverage,  or  selectively  shaped  area  coverage  by  combining  multiple, 
simultaneous  narrow  coverage  patterns.  A  high  gain,  narrow  transmit  coverage  capability 
is  provided  by  the  gimbaled  dish  anterma  (GDA).  The  receive  and  transmit  MBAs  have 
the  ability  to  simultaneously  cover  multiple  areas,  thereby  maximizing  link  gain  between 
terminals  in  the  illuminated  areas  and  reducing  the  effect  of  off  beam  jamming  signals. 
This  capability  is  not  normally  used  during  naval  operations,  but  may  be  employed  as 
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directed  for  contingencies.  [Lindberg] 

Capacity:  There  are  currently  62  commanders  afloat  and  ashore  using 
SHF  SATCOM.  Under  the  current  configuration  of  only  one  channel  per  satellite,  not  all 
ships  capable  of  coming  up  on  SHF  can  be  active  at  the  same  time.  [  Lindberg]  Those 
ships  capable  of  SHF  access  have  either  two  7-foot  antennas,  two  4-foot  antennas  or  one 
16-inch  antenna.  The  16-inch  submarine  SHF  antenna  is  rarely  utilized  due  to  the 
amount  of  power  required  for  transmission. 

Currently  as  of  FY98  the  CV/CVN  SHF  bandwidth  is  512-768  kbps  up  to 
1.5  Mbps  using  a  WSC-6  (V)  5.  The  CG  SHF  bandwidth  is  256  kbps.  The  DDG  SHF 
bandwidth  is  256  kbps.  The  LHD/LHD  bandwidth  is  512-768  kbps  up  to  1.5  Mbps 
maximum  using  a  WSC-6  (V)  5.  The  LCC/AGF  SHF  bandwidth  is  512-768  kbps  up  to 
3.0  Mbps  maximum  using  a  WSC-6  (V)  5.  Submarine  SHF  bandwidth  is  64  kbps. 
[IT21] 

The  last  four  DSCS  III  satellites  scheduled  for  launch  (B-8,  B-1 1,  B-6,  and 
A-3)  will  receive  performance  upgrades  through  the  DSCS  SLEP.  Responding  to  the 
Services'  need  for  more  capacity,  the  original  DSCS  III  SLEP  has  been  revised.  The 
revised  SLEP  provides  improved  satellite  capability  for  the  next  four  DSCS  satellites  to 
be  launched  with  the  first  scheduled  in  July  1999  and  the  fourth  in  fiscal  year  (FY)  2003 
(a  fifth  satellite  is  currently  unfunded).  Major  revised  SLEP  upgrades  to  the  DSCS  III 
satellite  include  increased  transponder  bandwidth  and  50- watt  TWTA  in  all  six  channels. 
The  50-watt  TWTA  and  bandwidth  addition  is  predicted  to  provide  a  700  percent 
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increase  in  tactical  communications  capacity.  Furthermore,  upgrades  to  the  low  noise 
amplifiers  (LNA)  is  estimated  to  provide  an  approximately  30  percent  increase  in  data 
rates  for  smaller  terminals.  The  increased  power  capability  in  all  chaimels  on  STEP 
DSCS  III  satellites  will  allow  shifting  of  nontactical  users  on  channels  2  through  4  to 
channels  5  and  6  by  using  bandwidth-efficient  modulation  techniques.  This  compression 
technique  provides  greater  bandwidth  utilization  but,  in  the  past,  was  not  feasible  due  to 
the  increased  power-per-bit  requirement.  STEP  v^ll  increase  the  mean  mission  duration 
(MMD)  from  7.5  to  10  years  per  satellite.  [Lindberg] 

Protection;  DSCS  SHF  security  components  include  KG-194’s  for  bulk 
encryption  and  KG-84’s  for  single  channel  encryption.  Currently  there  are  a  wide  variety 
of  modems  and  multiplexers  in  use.  The  configuration  depends  on  the  type  of  terminals 
connected  to  the  circuits. 

Access  and  Control:  DSCS  DAMA  as  proposed  by  DISA  will  be 
supported  by  FDMA  single  channel  per  carrier  (SCPC)  circuits  and  will  offer  a  broad 
range  of  messaging,  director,  port  in-network,  and  billing  services.  It  will  support  semi¬ 
permanent  fixed  bandwidth  and  bandwidth-on-demand  through  user  recognition.  DAMA  • 
Network  Control  Terminals  (NCT)  will  be  given  a  certain  amount  of  bandwidth  and 
power  to  manage.  These  allocations  may  not  be  confined  to  a  single  transponder  and  may 
not  be  contiguous  within  a  given  transponder.  The  majority  of  terminals  in  the  net  will  be 
multicarrier  capable.  It  should  be  noted  that  the  acronym  DAMA  when  used  as  the 
implementation  standard  in  SHF  DSCS  is  misleading  and  would  be  better  named  FDMA 
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Network  Management  System  (FNMS).  FNMS  is  defined  as  a  control  system  to  monitor 
and  control  links  using  standard  FDMA  modems  (OM-73,  EFD-8650,  and  CQM-248). 
[FAS]  FNMS  will  eventually  replace  the  Interim  Tactical  Orderwire  System 
(ITOSyGroimd  Mobile  Force  (GMF)  orderwires  (0/  W).  The  system  capabilities  include: 
login/  logout,  0/  W  services,  FDMA  link  setup  and  characterization,  FDMA  link 
maintenance  and  teardown,  NCT  handover,  remote  NCT  operations,  and  control  circuit 
transmission  security  (TRANSEC)  (CCT)  protection.  Eventually,  the  FNMS  will  replace 
the  Automatic  FDMA  Power  Control  and  Link  performance  reporting  functions  and  be 
able  to  control  links  on  leased  commercial  communications  satellite  transponders. 
[Lindberg] 

Each  transponder  chaimel  is  capable  of  relaying,  with  minimal 
performance  degradation,  time-division  multiplexer  (TDM)/FDMA,  CDMA,  and  time- 
division  multiple  access  (TDMA)  signals.  When  relaying  FDMA  signals,  the  transponder 
HPA  must  operate  in  an  essentially  linear  mode.  CDMA  and  TDMA  signals  permit 
operation  in  a  near-saturated  mode.  The  gain  of  the  transponder  is  controlled  prior  to  the 
TWTA/  HESSA  to  ensure  the  desired  degree  of  TWT  saturation  for  varying  input  levels. 
Input  variations  depend  on  the  number  of  uplink  signals  and  the  EIRP  of  the  Earth 
terminals.  [Lindberg] 

The  DSCS  III  Communications  Subsystem  includes  six  independent  RF 
channels,  jammer  location  electronics  (JLE),  one  receive  61-beam  MBA,  two  receive 
ECHs  (EIR  and  E2R),  two  transmit  19-beam  EC/  narrow  coverage  (NC)  MBAs  (MIX 


64 


and  M2X),  one  transmit  GDA,  and  two  transmit  ECHs  (EIX  and  E2X).  Channels  1  and  2 
are  designated  as  power  channels  and  each  operates  with  a  40-watt  TWTA.  Channels  3  to 
6,  the  low  power  channels  operate  with  a  combination  of  10- watt  TWTAs/  high 
efficiency  solid-state  amplifiers  (HESSA),  and  linear  solid-state  amplifiers  (LSSA). 
[Lindberg] 

Interoperability:  End  user  applications  supported  through  SHF  SATCOM 
systems  fall  in  four  general  categories:  command  and  control,  mission  planning/support, 
nontactical  initiatives,  and  SURTASS.  SHF  future  applications  envisioned  by  the 
Copernicus  Architecture  are  affected  by  the  major  restmcturing  of  Navy  C4I  to  put  the 
warfighter  at  the  center  of  the  command  and  control  universe.  The  Joint  Maritime 
Communications  Strategy  (JMCOMS)  provides  the  technical  and  implementation 
strategy  for  the  communications  portion  of  Copernicus.  JMCOMS  technical  thrusts  are 
designed  to  introduce  systems  that  facilitate  the  collection,  correlation,  and  fusion  of  data 
to  produce  and  efficiently  disseminate  information  that  is  required  by  joint  task  force 
(JTF)  and  joint  task  group  (JTG)  commanders  in  a  format  that  can  be  readily  used.  The 
major  components  of  Copernicus  are  the  CINC  Command  Complex  (CCC)  ashore,  the 
Tactical  Command  Centers  (TCC)  afloat,  the  Global  Information  Exchange  System 
(GLOBIXS),  Tactical  Data  Information  Exchange  System  (TADIXS),  and  Battle  Cube 
Information  Exchange  System  (BCIXS).  The  Navy  SHF  SATCOM  architecture  will 
support  Copernicus  by  providing  additional/supplemental  media  for  the  TADIXS  and 
BCIXS  networks.  The  Automated  Digital  Networking  System  (ADNS)  is  the  primary 
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JMCOMS  technical  thrust  for  integrating  the  Navy's  SHF  SATCOM  assets  into 
Copernicus.  [JMCOMS] 


DSCS  SHF  has  as  a  future  capability  to  be  compatible  with  ADNS.  As  of 
November  1997  SHF  DSCS  was  incompatible  with  ADNS.  Navy  SHF  packages  has 
very  rigid  COMMPLANs,  which  could  be  controlled  via  ADNS.  The  ADNS  capability 
is  being  built  into  the  future  DSCS  SHF  STEP  program  that  begins  launching  in  1999 
through  2003.  [JMCOMS] 

Latency:  SHF  has  a  nominal  240  millisecond  geosynchronous  delay.  The 
circuits  are  currently  dedicated  to  a  certain  band'width  vwthout  any  flexibility.  The 
significant  latency  delays  are  between  the  earth  stations  and  the  satellites.  None  of  the 
satellites  have  or  are  planned  to  have  on  board  processing;  they  are  all  in  bent-pipe 
configurations. 

2)  Commercial  High  Data  Rate  (HDR)  Wide  Band  (Challenge  Athena) 

Model:  Assumptions  include  the  use  of  Challenge  Athena  III  (Intelsat 
702);  2.4  Mbps  total  system  capacity  (divided  among  a  maximum  of  3  ships  using 
TDMA);  afloat  users  equipped  with  C-band  9-foot  antennas;  CA  available  to  the  CVN- 
with  a  nominal  throughput  of  768Kbps.  No  other  platforms  have  CA  other  than 
command  ships  and  big  deck  amphibious  assault  ships  (LHD/LHA). 

System  Description:  Challenge  Athena,  as  discussed  in  the  Backgroxmd, 
answers  the  fleets  call  for  additional  bandwidth.  CA  uses  leased  lines  and  Earth  stations 
to  integrate  into  the  DISN.  For  PACOM,  the  entry  site  is  at  Steele  Valley,  California. 
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This  site  is  connected  to  NCTS  San  Diego  via  three  T1  lines.  From  the  NCTS,  the 
military  traffic  is  connected  to  other  nodes  in  the  DISN  such  as  NCTAMS  EAST? AC  in 
Hawaii.  The  satellites  have  geostationary  positions  of  76  W,  21.3  W,  177  E,  1  W  and 
177E.  The  constellation  provides  near  worldwide  coverage.  There  is  gapped  coverage  in 
the  Indian  Ocean  region,  but  triple  coverage  in  the  Atlantic,  European  and  Middle  East 
regions.  The  satellite  transponders  are  also  leased.  A  typical  Intelsat  VII  satellite  (e.g., 
Intelsat  702)  is  capable  of  providing  42  channels  of  C-band  and  20  channels  of  Ku-band 
transmission.  The  latest  Intelsat  VIII  versions  can  provide  64  and  12,  respectively.  One 
of  the  biggest  drawbacks  of  CA  is  the  size  of  the  terminals.  The  terminals  weigh  1840 
pounds.  The  9  foot  antennas  are  housed  in  a  radome  that  is  13.5  feet  in  height. 
Understandably,  CA  is  only  available  to  big  deck  Navy  ships. 

3)  Commercial  Medium  Data  Rate  (MDR)  Wide  Band  (Inmarsat  B) 

Model:  Assumptions  include  the  use  of  Inmarsat  B  (HSD);  1.2  Mbps  total 
system  capacity  (divided  among  a  maximum  of  10  ships)  for  F3  satellite;  Inmarsat  is 
available  for  all  units  except  SSNs.  Nominal  unit  throughput  is  64  Kbps. 

System  Description:  Inmarsat-B  High  Speed  Data  (HSD)  was  launched  in 
1993  as  the  digital  successor  to  Inmarsat-A.  Inmarsat-B  (HSD)  provides  a  global  satellite- 
based  extension  of  the  terrestrial  ISDN  network  to  users  who  would  otherwise  be  unable 
to  access  ISDN.  Three  features  make  Inmarsat-B  (HSD)  unique  when  compared  to  other 
satellite  communications  service  providers:  (1)  On-demand  satellite  capacity,  (2) 
seamless  worldwide  coverage,  and  (3)  Direct  dial  access  to  the  global  ISDN  network. 
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[Inmarsat] 


Coverage:  Four  geostationary  satellites  (178  E,  54  W,  15.5  W,  and  64  E) 
provide  continuous  worldwide  coverage. 

Capacity:  Using  robust  file  transfer  protocols  such  as  TCP/IP,  average 
throughputs  of  60  kbps  on  a  64  kbps  channel  along  with  full  error  correction  and  data 
recovery  is  possible  using  Inmarsat-B  (HSD).  Although  the  Inmarsat-B  (HSD)  is  best 
suited  to  operate  in  environments  where  a  56/64  kbps  terrestrial  connection  is  available  at 
the  Land-Earth  Station  (LES),  the  service  can  still  function  without  the  terrestrial 
connection,  however  the  LES  will  be  limited  only  to  mobile-to-mobile  service. 
Therefore,  the  growth  and  demand  of  Inmarsat-B  HSD  is  clearly  linked  to  the  availability 
and  growth  of  ISDN.  Inmarsat-B  (HSD)  also  supports  medium  speed  data  service  that 
provides  a  9.6  kbps  circuit  through  the  terrestrial  PSTN  to  normal  dial-up  modems. 
Some  of  the  typical  HSD  applications  include  multiplexed  voice,  data,  and  fax,  audio 
uplinks,  store  and  forward  video,  videoconferencing,  and  LAN  interconnections.  Each 
Inmarsat-B  (HSD)  multiplexed  voice,  data  and  fax  channel  provides  a  duplex  64  kbps 
data  channel  that  may  be  multiplexed  to  carry  2  to  10  users.  Audio  applications  use  7.5 
or  15  kHz  audio  codecs  to  provide  broadcast-quality  audio  from  remote  locations.  Under 
the  video  store  and  forward  concept,  each  HSD  channel  transfers  data  at  a  much  lower 
rate  than  video  applications  require.  Therefore,  the  video  is  captured  at  rates  ranging 
from  512  kbps  to  3  Mbps  and  then  is  transferred  using  the  56/64  kbps  HSD  channel. 
Once  at  the  final  destination,  the  video  is  then  stored  and  played  back  at  the  original  rate. 
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LAN  interconnections,  such  as  (but  not  limited  to)  those  supported  by  TCP/IP-based 
protocols  are  also  supported  by  Inmarsat-B  HSD. 

Access:  The  preferred  multiplexing  technique  for  most  efficient  use  of  the 
fixed  bandwidth  channels  is  statistical  multiplexing  (Demand  Assignment).  DAMA  is 
used  by  both  the  remote  and  terrestrial  links.  For  mobile-to-fixed  calling,  LES  selection 
is  made  by  the  Mobile  Earth  Station  (MES)  either  using  the  default  code  programmed 
into  the  MES  or  by  the  user  entering  an  LES  code  while  dialing.  For  fixed-to-mobile 
calling,  the  system  requires  the  telephone  service  provider  recognize  the  correct  region 
called  and  the  type  of  service  to  be  provided  for  correct  LES  routing.  For  mobile-to- 
mobile  calling  (which  is  consistent  with  those  areas  not  offering  terrestrial  56/64  kbps 
connections),  there  is  an  additional  delay  introduced  due  to  the  double  satellite  hop  which 
will  reduce  throughput  in  most  applications. 

Interoperability:  Inmarsat-B  HSD  land-mobile  terminals  typically  cost 
$30-40  K  US  dollars.  This  is  about  half  the  price  of  VSAT  that  runs  $50-100  K  US 
dollars  depending  on  the  anteima  size  and  system  (C-band  or  Ku  band).  Size  of  the 
Inmarsat  system  is  a  particularly  attractive  element  for  mobile  maritime  applications. 
The  Inmarsat-B  (HSD)  system  typically  weighs  approximately  18-30  kgs  and  has  an 
antenna  size  of  about  1  meter.  It  can  easily  be  transported  in  a  small  aircraft  (COD)  or 
helicopter.  Untrained  personnel  can  do  deployment  and  setup  in  a  matter  of  minutes, 
with  permanent  installations  taking  only  a  few  hours.  [Inmarsat] 

Latency:  Channel  delays  from  the  satellite  link  vary  with  the  LES  but  are 
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typically  on  the  order  of  250  ms.  For  mobile-to-mobile  communications,  the  delays  may 
approach  2  seconds. 

4)  High  Frequency 

Model:  Assumptions  include  the  use  of  ground  wave  HF  vvith  HF  fleet 
radio,  the  RF-326'IE,  which  can  deliver  2.4  kbps  at  a  range  of  500  nautical  miles(nm). 
For  simplicity,  one  radio  was  assigned  per  ship,  but  multiple  radios  could  be  added.  In 
addition,  the  CVN  was  configured  to  conduct  long-haul  HF  communications  at  2.4  kbps 
but  the  other  twelve  ships  were  configured  to  use  HF  relay  at  64  kbps.  The  HF  relay 
allows  users  to  send  data  to  the  carrier  to  subsequently  be  sent  out  the  CVN’s  SHF  or 
Challenge  Athenat  The  relay  concept  is  similar  to  the  UHF  relay  envisioned  in  the 
Digital  Wideband  Transmission  System  (DWTS)  for  amphibious  forces.  DWTS  can 
provide  up  to  2.048  Mbps  of  additional  bandwidth  for  the  littoral  region.  [IT21] 

System  Description:  High  fi’equency  (HF)  communications  have  been 
employed  (especially  by  the  United  States  Navy)  since  the  beginning  days  of  wireless 
radio.  Traditionally,  the  HF  spectrum  used  by  the  Navy  ranges  fi-om  2  to  30  MHz.  The 
deployment  of  modem  communication  satellites  ended  the  Navy’s  reliance  on  long-range 
(greater  than  500  nm)  HF  communications.  In  addition,  the  Navy  turned  away  fi-om  sky 
wave  HF  and  began  to  develop  ground  wave  HF.  Tests  have  shovm  that  ground  wave 
waveforms  are  less  likely  to  be  affected  by  fading  and  scintillation.  [Pinck]  However, 
ground  wave  HF  does  not  provide  as  much  range  (on  the  Earth’s  surface)  as  sky  wave  HF 
due  to  the  extended  propagation  field  of  view  provided  by  the  atmosphere. 
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Capacity:  The  current  HF  fleet  radio,  the  RF-3261E  can  deliver  2.4  kbps 
at  a  range  of  500  miles.  Many  initiatives  have  sought  to  increase  the  available  data  rate 
provided  by  the  RF-3261E.  A  test  conducted  at  SPASYSCEN  San  Diego  CA  for  the 
NAVCOASYSSTA  Panama  City,  Florida  demonstrated  the  feasibility  of  using  HF 
beyond  the  line-of-sight  (BLOS)  to  support  a  communications  link  between  a  semi- 
submersible  mine  hunter  and  it’s  parent  vessel.  At  ranges  of  less  then  25  nautical  miles 
the  system  supported  data  rates  varying  from  56k  to  75  kbps.  [Pinck] 

HF  data  rate  depends  on  the  environmental  conditions.  To  combat  poor 
environmental  conditions  or  fading  one  has  to  use  a  combination  of  bandwidth  efficient 
modulation  techniques  and  forward  error  correction  coding.  The  reader  is  referred  to 
Rappaport  for  an  in  depth  discussion  on  the  interrelationships  between  data  rate,  fading, 
modulation  and  forward  error  correction  coding. 

A  brief  discussion  to  reduce  enviromnental  effects  and  optimize  HF  data 
rate  follows.  As  a  communications  signal  propagates  from  the  transmitter  to  the  receiver, 
energy  is  lost  due  to  scattering,  reflection,  and  diffraction.  These  effects  are  characterized 
as  fading,  which  includes  both  large  and  small  scale  fading.  For  a  ship  that  moves  over 
distances  that  are  large  compared  to  the  wavelength,  fluctuations  in  receiver  signal 
strength  are  characterized  as  large  scale  fading.  Large  scale  fading  represents  the  loss 
introduced  by  the  channel.  In  contrast,  small  scale  fading,  or  simply  fading,  occurs  when 
a  ship’s  motion  is  short  compared  to  the  wavelength.  Small  scale  fading  causes  the 
received  signal  to  induce  inefficiency  by  causing  rapid  changes  in  the  signal’s  amplitude 
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and  phase. 

Likewise,  when  transmitting  in  unguided  mediums  (i.e.,  the  atmosphere)  a 
signal  can  arrive  at  the  receiver  via  multiple  paths.  These  multiple  paths  can  be  due  to 
obstructions,  ground  reflections,  or  scattering  within  the  channel.  The  receiver  sums  the 
multipath  contributions;  but  since  the  multipath  components  vary  -widely  in  phase,  the 
signal  at  the  receiver  can  also  fluctuate.  Subsequently,  the  sum  of  the  multipath 
components  can  be  either  constructive  or  destructive.  Nevertheless,  multipath  in  the 
channel  creates  small  scale  fading  effects.  The  three  most  important  effects  are  (1)  rapid 
changes  in  received  signal  strength  over  distances  short  compared  to  a  wavelength,  (2) 
random  frequency  modulation  due  to  varying  Doppler  shifts  on  different  multipath 
signals,  and  (3)  time  dispersion  caused  by  multipath  propagation  delays.  [Rappaport] 

In  addition  to  reducing  the  fading  just  discussed,  the  proper  selection  of 
modulation  can  optimize  chaiuiel  performance.  Choices  for  modulation  include  M-ary 
phase  shift  keying  (MPSK)  and  M-ary  frequency-shift  keying  (MFSK),  PSK  (BPSK) 
and  QPSK.  A  modulation  technique  that  maintains  the  highest  performance  and  spectral 
efficiency  as  possible  should  be  chosen.  If  satisfactory  performance  for  the  link  is 
defined  as  a  probability  of  bit  error  smaller  than  10’^  for  a  given  SNR  of  twelve  dB,  the 
appropriate  choice  for  modulation  is  QPSK.  Calculations  using  equations  fi-om  Rappaport 
support  this  conclusion. 

Given  the  effects  of  a  fading  channel,  the  use  of  forward  error  correction 
(FEC)  is  one  way  to  improve  performance  (by  detecting  and/or  correcting  errors).  The 
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additional  bits  improve  the  system’s  performance  (i.e.,  probability  of  bit  error)  without 
increasing  SNR.  Unfortimately,  an  unavoidable  consequence  of  using  FEC  is  data  rate 
reduction  by  a  factor  equal  to  the  code  rate.  This  means  that  the  cost  of  coding  gain  leads 
to  either  an  increase  in  bandwidth  or  a  reduction  in  bit  rate.  Likewise,  the  greatest 
disadvantage  to  using  FEC  is  the  additional  bandwidth  required  by  the  code.  This 
additional  bandwidth  lowers  the  potential  system  data  rate.  However,  without  the 
additional  coding  gain  provided  by  FEC,  the  forward  link  carmot  meet  the  probability  of 
bit  error  performance  requirement  of  10'^.  [Rappaport] 

It  can  be  shown  that  a  combination  of  soft  decision  decoding  and 
concatenated  FEC  coding  improves  system  performance.  For  example,  a  test  conducted 
between  USS  Coronado  and  USS  Cleveland  during  RIMPAC-98  successfully 
demonstrated  a  HF  data  link  at  a  maximum  range  of  147  nm  and  a  nominal  range  of  1 10 
nm  [Pinck].  The  test  concluded  that  a  quadrature  phase  shift  keyed  signal  using  a 
concatenated  forward  error  correction  code  supported  a  data  rate  varying  from  56k  to  75 
kbps.  At  a  range  of  50  nm  or  less  the  system  was  able  to  deliver  a  data  rate  of  75  kbps;  at 
110  run  64  kbps;  at  147  nm  56kbps,  and  at  500  nm,  the  RF-32,61E  is  capable  of  2.4  kbps. 

Clearly,  a  QPSK  concatenated  system  significantly  increases  the  date  rate 
of  each  RF-3261E.  Nevertheless,  to  deliver  higher  data  rates  to  support  the  larger 
volumes  of  data  required  for  wireless  Internet  operations,  the  implementation  of  a 
mulitcarrier  system  is  recommended  (assuming  that  the  limiting  factor  is  the  channel 
coherence  bandwidth).  In  a  multicarrier  system,  the  data  stream  is  broken  up  into  as 
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many  as  m  bit  streams  that  are  individually  transmitted  on  up  to  m  different  frequencies 
where  the  subscript  i  =  \,2,3,...,m  uniquely  identifies  the  carrier  frequency. 

For  QPSK,  a  single  carrier  system  provides  a  data  rate  equal  to  the  bit  rate.  For  a 
multicarrier  system  having  the  same  bit  rate,  each  of  the  m  multicarrier  system 

frequencies  will  provide  a  data  rate  equal  to  =  — .  Therefore,  the  bandwidth  of  each 

'  m 

multicarrier  frequency  is  1/m  times  smaller  than  that  of  the  single  carrier  system.  As  a 
result,  if  a  Ticonderoga  cruiser  uses  three  RF-3261E  radios  at  a  range  of  1 10  nm,  the  ship 
could  increase  HF  data  rate  from  64  kbps  to  192  kbps. 

Additional  means  can  also  improve  the  available  HF  bandwidth.  Current 
communications  doctrine  eissigns  each  HF  user  with  a  set  of  frequencies.  If  the  Navy 
abandoned  this  FDMA  approach  and  allowed  dynamic  allocation,  the  HF  bandwidth  data 
rates  would  be  maximized  more,  while  preventing  distortion.  In  addition,  the  master 
controller  (MC)  could  dynamically  assign  different  FEC  types  and  constraint  lengths, 
thereby  providing  enough  coding  gain  to  maintain  the  desired  link  margin  and 
minimizing  the  use  of  code  that  unduly  burdens  the  available  data  rate. 

5)  Commercial  Mobile  Satellite  Service  (MSS) 

Model:  Assumptions  include  a  single  handset  per  ship,  2.4  kbps  unit 
throughput,  TDMA  transponder  access  with  ten  active  users;  cross-link  time  is  2  msec; 
satellite  altitudes  are  787  km. 

System  Description:  Sixty  six  cross-link  capable  low  earth  orbit  (LEO) 
satellites  in  six  planes  provide  global  coverage.  The  system  can  support  up  to  3840 
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simultaneous  users  per  satellite.  Multiple  access  is  provided  via  TDMA.  The  system 
utilizes  a  QPSK  modulation  scheme.  Current  capability  does  not  provide  dual  mode 
(cellular  and  satellite)  use  but  will.  [Hampton]  Handsets  cost  approximately  $3000  each 
and  typical  service  costs  are  advertised  to  be  $3.00  per  minute.  Additional  crypto  sleeves 
add  approximately  $2,000.  Thus,  in  addition  to  the  PSTN,  connectivity  is  provided  with 
DRSN  and  DSN.  In  January  1998  the  U.S.  military  purchased  a  gateway  ($14.5  million), 
which  is  co-located  in  the  same  building  as  the  GBS  SBM  in  Wahiawa,  Hawaii.  [Yee] 
This  fixed  DoD  gateway  will  provide  additional  security  for  military  users.  The  gateway 
will  support  up  to  120,000  users.  The  latency  of  5  milliseconds  is  low  compared  to  the 
geosynchronous  satellites. 

6)  Ultra  High  Frequency  DAMA 

Model:  Assumptions  include  use  of  UFO-8,  25  khz  UHF-DAMA  protocol, 
four  users  per  system  chaimel;  all  units  UHF  capable. 

System  Description:  UHF  systems  support  thousands  of  users  ashore  and 
afloat.  The  UHF  follow-on  satellite  system  (UFO)  is  replacing  the  Fleet  Satellite 
Communications  (FLTSATCOM)  and  the  Leased  Satellites  (LEASAT),  which  provide 
links  between  naval  aircraft,  ships,  submarines  and  ground  stations.  The  UFO  satellites 
offer  increased  communications  channel  capacity  over  the  same  frequency  spectrum  as 
the  current  systems.  Each  spacecraft  has  1 1  UHF  amplifiers  and  39  UHF  channels  with  a 
total  555  kHz  bandwidth.  These  frequencies  consist  of  21  narrowband  channels  at  5  kHz 
each  and  17  relay  channels  at  25  kHz.  In  comparison,  FLTSATCOM  offers  22  channels. 
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The  FI  through  F7  spacecraft  include  an  SHF  subsystem,  which  provides  redundant 
command  and  ranging  capabilities  when  the  satellite  is  on  station  as  well  as  the  secure 
uplink  for  Fleet  Broadcast  service,  which  is  downlinked  at  UHF.  [Shumadine] 

The  UFO  satellites  will  improve  UHF  protection  against  electronic  threats 
as  well  as  host  the  interim  GBS  capability  onboard  F8  through  FIO  as  previously 
discussed.  Satellites  F4  through  FIO  also  have  a  MILSTAR-compatible  EHF  package 
with  enhanced  anti-jam  communication  capabilities.  This  addition  includes  11  EHF 
channels  distributed  between  an  earth  coverage  beam  and  a  steerable  5-degree  spot  beam. 
Beginning  with  satellite  F7,  the  EHF  package  has  been  enhanced  to  provide  20  channels 
through  the  use  of  advanced  digital  integrated  circuit  technology.  For  network  control 
purposes.  Demand  Assigned  Multiple  Access  (DAMA)  controllers  will  maximize  use  of 
5-  and  25-kHz  channels  to  meet  user  needs. 

Coverage:  UHF  SATCOM  theoretically  provides  excellent  near 

worldwide  coverage  from  65°  N  to  65°  S.  The  coverage  does  not  appear  to  fully  extend 
across  the  United  States  and  excludes  a  portion  of  the  eastern  Pacific  Ocean  from  about 
80°  W  to  105°  W.  [Shumadine] 

Capacity:  The  typical  maximum  number  of  simultaneous  TCP/IP  users 
that  the  ADNS  UHF  DAMA  channel  access  protocol  (CAP)  can  support  is  four.  [Arthur] 
The  25  kHz  UHF  DAMA  system  was  originally  designed  to  support  point-to-point, 
conference,  and  network  calls.  Its  associated  data  rates  are  75  bps  -  16  kbps.  The  5  kHz 
UHF  DAMA  system  was  originally  designed  to  provide  short  data  messages,  low  speed 
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data  circuits,  and  limited  secure  voice  capability.  Its  associated  data  rates  are  75  bps  - 
4.8  kbps.  In  order  to  utilize  (TCP/IP),  the  UHF  DAMA  system  has  to  be  analyzed  within 
the  framework  of  an  interface  to  the  protocol.  An  interface  that  can  be  used  is  the 
Automated  Digital  Network  System  (ADNS).  In  this  context,  the  typical  mode  of 
operation  for  ADNS  and  UHF  DAMA  for  the  Navy  is  the  assignment  of  a  2.4  kbps  slot 
on  a  25-kHz  DAMA  channel. 

Protection:  Security  for  the  UHF  SATCOM  system  is  largely  dependent 
upon  the  user’s  terminal.  All  terminals  employ  security  measures.  Of  the  three  main 
terminals,  AN/WSC-3,  LST-5D,  and  AN/ARC-187,  only  the  LST-5D  has  embedded 
security.  The  other  two  terminals  utilize  extema.1  security  features.  The  AN/WSC-3  is 
the  standard  shipboard  terminal.  The  level  of  security  for  the  reach  back  channel  over 
UHF  DAMA  would  be  comparable  to  the  UHF  MILSATCOM  Fleet  Broadcast. 

Access:  UHF  demand  assigned  multiple  access  (DAMA)  satellite 
communications  is  the  most  widely  available  long  haul  system  to  members  of  the  armed 
services.  Often,  it  may  be  the  only  communications  capability.  As  such,  it  is  a  prime 
candidate  to  provide  a  reach  back  path  for  GBS.  When  UHF  DAMA  is  the  primary 
means  of  long  haul  communications,  manual  retransmit  request  will  be  utilized.  [Arthur] 

There  are  currently  two  different  UHF  DAMA  SATCOM  waveforms,  one 
for  operation  over  5-kilohertz  (kHz)  channels,  and  one  for  operation  over  25-kHz 
channels.  The  Navy  has  focused  on  the  development  of  the  25-kHz  DAMA  controllers 
and  terminals  for  both  ships  and  aircraft,  while  the  Air  Force  has  concentrated  on  the  5- 
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kHz  DAMA  controllers  and  terminals. 


The  two  modes  of  operation  for  channel  assignment  is  distributed  control 
(DC)  and  automatic  control  (AC).  The  DC  mode  involves  centralized  assignment  of  time 
slots  within  the  chaimel.  The  control  site  determines  how  the  DAMA  slots  are  allocated 
and  distributes  the  assignments.  In  the  DC  mode,  there  is  no  dynamic  reallocation  of 
bandwidth.  In  the  AC  mode,  a  time  slot  is  requested  from  a  central  controller,  assigned  to 
a  terminal,  and  released  back  to  the  controller  once  the  terminal  has  completed  using  it. 
An  additional  capability  when  operating  in  the  AC  mode  is  called  demand  assigned  single 
access  (DASA).  The  DASA  mode  allows  a  single  user  access  to  an  entire  channel 
without  having  to  share  the  bandwidth.  The  request  for  a  DASA  channel  is  made  via  the 
user’s  UHF  DAMA  channel.  In  the  DASA  mode  of  operation,  once  the  channel  has  been 
assigned  to  a  user,  it  is  operated  in  the  dedicated  UHF  SATCOM  mode.  The  user  retains 
access  of  the  DASA  channel  until  the  channel  is  voluntarily  released  and  the  user  logs 
back  onto  his  home  chaimel  or  the  timer  expires.  DASA  channels  cannot  be  preempted. 
[Arthur] 

Latency:  When  using  UHF  DAMA  as  a  GBS  reach  back  channel  there  is  • 
a  substantial  time  delay  associated  with  the  DAMA  protocol  itself.  In  fact,  UHF  DAMA 
may  represent  a  worst  case  scenario  for  timing  delays.  For  the  25  kHz  version,  the 
minimum  time  to  request  and  access  a  time  slot  is  three  frames.  Each  frame  delay  is 
approximately  1 .4  seconds.  A  typical  time  would  then  be  3  frames  plus  two  satellite  hop 
delays,  approximately  4.6  seconds  total.  For  the  5  kHz  version,  the  entire  frame  is  8.96 
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seconds  in  duration,  but  the  lengths  of  the  time  slots  assigned  for  circuit  use  within  the 
frame  vary  with  the  type  of  data,  modulation,  and  code  rate.  The  minimum  time  to  set  up 
a  channel  is  also  3  frame  cycles  or  almost  27  seconds  and  could  be  longer  if  more,  higher 
priority  users  are  competing  for  the  channel.  Once  the  circuit  is  established  the  worst 
case  delay  would  be  at  most  two  frames  which  makes  full  duplex  data  communications 
difficult,  and  voice  communications  even  more  difficult.  Due  to  the  difference  in  delays, 
the  25  kHz  channel  is  the  preferred  method  for  communications.  Table  8  provides  an 
indication  of  UHF  DAMA  total  time  to  complete  a  reach  back  session  (time  from  first 
synchronization  [SYNC]  sent  from  the  RDM  until  the  final  ACK  is  received  to  close  out 
the  TCP  session).  Likewise,  it  should  be  noted  that  a  significant  amount  of  this  time  was 
attributed  to  ACK  times.  For  example,  average  times  for  first  ACK  for  four  users  no 
load,  25%  load  and  50%  load  are  17.24, 26.77  and  41.32  seconds,  respectively.  [Arthur] 


Direct  Con. 

■  2  User 

4  User  No  Load 

4  User  25%  Load 

4  User  50%  Load 

Attempts/Successful 

10/10 

10/10 

10/10 

10/13 

0/14 

Percent  Successful 

100% 

100% 

100% 

76.9% 

0% 

Mean  Time 

1.356 

78.76 

79.31 

112.01 

NA 

Standard  Deviation 

0.079 

2.95 

3.21 

5.58 

NA, 

Table  8.  Total  Time  to  Complete  UHF  DAMA  Reach  Back  [Arthur] 


A  5-kHz  DASA  circuit  may  be  set  up  using  a  25-kHz  channel  or  a  5-kHz 
channel  to  request  the  circuit.  The  use  of  a  25-kHz  channel  greatly  decreases  the  setup 
time.  In  the  DASA  mode  of  operation  once  the  channel  has  been  assigned  there  are  no 
framing  delays,  only  the  satellite  delay.  However,  the  inflexibility  of  the  DASA  channels 
for  preemption  does  not  make  it  a  good  candidate  for  reach  back. 
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Interoperability:  UHF  DAMA  cannot  support  a  direct  connection  between 
two  computers  without  a  third  party  system  to  govern  data  access  to  the  channel  or  time 
slot.  The  system  that  can  perform  this  task  for  UHF  DAMA  is  the  ADNS  UHF  DAMA 
CAP  (Channel  Access  Protocol).  The  normal  configuration  for  a  UHF  DAMA  SATCOM 
data  connection  is  from  the  ship  to  a  regional  Naval  Computer  and  Telecommunications 
Master  Station  (NCTAMS)  where  the  information  can  be  sent  forward  via  a  terrestrial 
SIPRNET  cormection. 

The  main  ingredient  for  TCP/IP  over  DAMA  for  ADNS  is  the  CAP 
Router  Interface  Unit  (CRIU).  Since  the  channel  has  a  relatively  high  latency,  it  is  likely 
that  the  originating  computer  will  have  generated  duplicate  packets  in  establishing  the 
TCP  session  due  to  the  retransmission  timer.  The  ADNS  CRIU  removes  these  duplicate 
packets  rather  than  sending  them  over  an  already  bandwidth  limited  link.  The  CRIU  is 
responsible  for  policing  the  link  and  developing  its  own  pseudo-retransmission  timer 
based  on  channel  latency  to  determine  when  a  packet  may  have  been  lost.  The  ADNS 
channel  access  method  is  less  efficient  at  lower  loads,  but  more  efficient  as  the  net 
becomes  congested: 

7)  Extra  High  Frequency 

Model:  Assumptions  include  use  of  UFO-8  (i.e.,  MILSTAR  and  the 
Interim  Polar  EHF  System  are  not  considered),  TDMA  access  among  EHF  capable  units, 
2.4  kbps  nominal  data  rate  for  users,  satellite  processing  adds  20  milliseconds  of  delay, 
all  units  EHF  capable  except  FFGs  and  AOE. 
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System  Description:  The  extremely  high  frequency  (EHF)  secure 
communications  links  provides  the  Navy  with  anti-jam  (AJ),  low  probability  of  intercept 
(LPI),  and  low  probability  of  detection  (LPD)  capability  for  command  and  control  of  the 
fleet.  The  LPI/LPD  features  of  EHF  could  allow  transmissions  during  EMCON.  In 
terms  of  MILSATCOM  architecture,  EHF  comprises  the  protected  segment.  This  is  due 
largely  to  the  ■wider  bandwidths  at  EHF,  narrow  antenna  beamwidth,  spread  spectrum 
techniques,  and  advanced  signal  processing  at  the  satellite.  Four  available  systems  now 
provide  EHF  communications  links  to  the  military:  the  Fleet  satellite  EHF  Package 
(FEP),  the  UHF  follow-On  /  EHF  Package  (UFO/E),  MILSTAR  and  the  Interim  Polar 
EHF  System.  The;  FEP  consists  of  two  operational  satellites;  FEP-7  over  CONUS  at  100 
W  (December  1986),  and  FEP-8  over  the  Atlantic  ocean  at  23  W  (September,  1989). 
[Hedges]  These  two  operational  satellites  are  the  primary  UHF  fleet  satellites  with 
installed  EHF  payloads.  [Hedges] 

Coverage:  The  FEP  does  not  provide  worldwide  coverage  since  only  two 
geosynchronous  satellites  exist  in  the  western  longitudes  (060  E  to  180  E  not  covered). 
However,  the  UFO/E  and  the  UFO/EE  together  pro-vide  excellent  worldwide  coverage 
that  extends  from  70°  N  to  70°  S.  The  UFO/E  system  currently  has  three  operational 
satellites  (UFO/E-4  through  UFO/E-6).  An  Enhanced  UFO/E  Package  (UFO/EE),  part  of 
the  UFO/E  satellite  system,  has  two  satellites  flying  (UFO/EE-7,  8)  with  plans  to  have 
UFO/EE-9  operational  in  November  of  1998  and  UFO/EE-1 0  operational  in  April  of 
1999.  [Hedges] 
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Capacity;  These  two  operational  satellites  can  accommodate  26  low  data 
rate  (LDR)  channels  that  can  be  mapped  to  either  beam.  Uplink  (U/L)  and  downlink 
(D/L)  frequencies  are  44  and  20  GHz  respectively.  The  primary  data  rates  per  channel 
are  75,  1200  and  2400  bps.  The  secondary  data  rates  per  channel  are  75,  150  and  300 
bps.  The  difference  in  throughput  represents  the  tradeoff  with  secure  communications, 
i.e.,  as  the  level  of  encryption  and  forward  error  correction  (FEC)  encoding  rises,  for  the 
same  bandwidth,  the  information  throughput  is  reduced.  TDMA  is  used  to  support 
multiple  users  from  the  terminals.  Four  terminal  charmels  can  be  multiplexed  to  achieve 
a  9.6  kbps  throughput.  The  downlink  frequency  is  SHF  only  and  no  crosslinks  are 
available  for  this  system.  Antenna  beams  used  are  earth  coverage  (EC)  and  spot  beams 
(no  agile  beams).  FEP  links  to  submarines  are  only  supported  during  research, 
development,  testing  and  evaluation  (RDT&E).  This  is  due  to  a  complete  payload 
reconfiguration  required  to  use  this  capability,  which  would  deny  support  to  other  EHF 
users  until  returned  to  original  configuration.  This  system  does  not  support  UHF 
broadcasts.  [Hedges] 

The  enhanced  version  of  EHF  includes  balanced  U/L  and  D/L  hops  and  20 
channels,  while  the  original  system  only  provides  hops  on  1 1  U/L  channels.  Antenna 
beams  used  are  earth  coverage  (EC)  and  spot  beams  (no  agile  beams).  The  primary  and 
secondary  data  rates  are  identical  to  the  FEP.  Also,  TDMA  is  used  to  support  multiple 
users.  However,  the  UFO/E  and  UFO/EE  are  EHF-UHF  crossbanded  at  75,  1200,  2400, 
4800,  and  9600  bps.  [Hedges] 
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Access:  Four  channels  per  terminal  are  available  to  the  user  with 
throughput  available  up  to  2400  bps  per  channel.  The  network  control  terminal  defines 
the  network  ID,  priority,  data  rate,  beams,  D/L  modes,  etc.,  which  then  sends  an 
activation  request  to  the  payload.  An  onboard  resource  controller  checks  for  available 
channels.  If  the  resources  are  available,  the  payload  assigns  them  and  sends  the  ground 
station  an  ‘ack.’  If  resources  are  imavailable  the  payload  checks  channel  use  priority  and 
preempts  lower  priority  channels  to  make  resources  available.  If  resources  cannot  be 
made  available,  the  payload  sends  back  an  ‘ack’  that  denies  network  activation.  [Hedges] 
Latency:  EHF  communications  links  have  additional  delays  for  two 
reasons.  First,  the  satellites  are  not  bent  pipes.  The  payload  performs  advanced  signal 
processing  before  transmitting  the  signal  back  to  earth.  This  signal  processing  includes 
demodulating,  de-interleaving  and  decoding  at  the  receive-end,  and  encoding, 
interleaving  and  modulating  at  the  transmit-end.  Second,  there  is  also  FEC  encoding, 
which  provides  reduced  bit  error  rates  but  at  the  expense  of  information  throughput.  FEC 
encoding  also  increases  the  probability  that  the  message  sent  is  received.  [Hedges] 

b.  Implementing  ADNS for  Radio-WAN  Management 
ADNS  can  be  thought  of  as  a  “black  box”  for  RE  management  that 
dynamically  chooses  the  best  “cost”  path  for  a  packet  to  be  routed.  ADNS  can  manage 
RF  channels  by  integrating  all  available  transmissions  systems  for  a  unit  (i.e.,  ship)  into 
one  system.  [Rehard]  The  integration  is  accomplished  with  the  use  of  a  system  CAP 
(Channel  Access  Protocol).  The  model  incorporates  an  ADNS  “black  box”  aboard  all 
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ships  and  at  the  NCTAMS  (Naval  Computer  and  Telecommunications  Command).  The 
number  of  CAPs  that  a  ship  has  depends  on  the  ship’s  communications  capabilities  (or 
number  of  available  reach  back  channels). 

Just  like  ADNS,  the  model  has  the  capability  to  prioritize  packets  by 
source  users  (via  IP  addresses)  and  application  (e.g.,  FTP  and  Email)  if  more  than  one 
packet  is  waiting  to  be  routed.  The  source  prioritizing  is  done  within  the  ADNS’  CRJU 
(Channel  Access  Protocol,  CAP,  to  Router  Interface  Unit).  If  two  or  more  packets  are 
waiting  in  the  CRIU  queue,  the  packet  with  the  lowest  number  priority  is  sent  first.  See 
Table  3  for  the  default  assignment  of  these  priorities.  After  the  CRIU,  the  packets  are 
sent  to  an  ADNS  CAP  (e.g.,  SHF).  The  CAP  queue  prioritizes  packets  based  on  an 
application’s  port  number.  Thus,  the  CAP  allows  an  FTP  packet  to  have  precedence  over 
an  Email  packet  since  the  FTP  packet  has  a  lower  port  priority  number.  See  Table  5  for 
the  default  assignment  of  port  priorities.  Other  model  priority  schemes  are  incorporated 
based  on  packet  attributes  such  as  node  identification,  classification  and  product  request. 
Classification  and  product  request  default  values  are  listed  in  Tables  4  and  6, 
respectively.  These  additional  priorities  are  implemented  at  the  CAP  queue,  but  are- 
lower  in  precedence  than  the  port  priority. 

When  the  CRIU  receives  IP  packets  fi'om  the  ADNS  IP  router,  the  CRIU 
forwards  the  packet  to  the  best  “cost”  path  based  on  a  congestion  control  algorithm.  This 
algorithm  determines  the  best  path  based  on  the  initial  RF  system  bandwidth,  the  current 
system  use,  the  unit’s  bandwidth  allocation  and  the  unit’s  current  use  of  that  system. 
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Any  RF  system  that  has  an  ADNS  CAP  can  be  selected  as  the  path  for 
transmission.  In  the  model,  the  queue  lengths  provide  an  indication  of  chaimel  use  for 
both  the  unit  channel  and  the  overall  system  channel.  The  cost  is  dynamically  computed 
for  each  RF  channel  and  compared  to  all  other  channels.  The  channel  with  the  lowest 
calculated  “cost”  is  chosen  as  the  transmission  path.  ADNS  also  includes  the  ability  to 
conduct  load  balancing  across  similarly  sized  radio  links.  For  example,  if  the  “congestion 
cost”  for  SHF  and  CA  are  equal,  then 

ADNS  will  send  every  other  packet  to  each  channel.  The  Extend  model  incorporates  this 
feature,  but  can  load  balance  only  when  system  capacities  are  set  to  be  equal.  Otherwise 
the  congestion  cost  algorithm  will  never  compute  equal  costs. 

As  discussed,  many  functions  of  ADNS,  including  port  and  IP  address 
prioritization,  open  shortest  path  first  (OSPF)  type  routing,  and  load  balancing  are 
incorporated  into  the  model.  Figure  15  shows  a  typical  ADNS  model  block.  A  packet 
can  be  transmitted  on  any  of  the  seven  reach  back  charmels.  To  route  the  packet,  ADNS 
takes  into  account  the  available  system  bandwidth  (and  it’s  current  use  or  queue  size)  and 
the  unit’s  bandwidth  (and  it’s  current  use).  Every  possible  path  is  compared  before 
sending  the  packet  to  a  back  chaimel.  Likewise,  if  any  channels  have  equal  costs,  the 
subsequent  packets  will  be  “load  shared”  equally  between  the  channels.  Figure  16 
shows  the  actual  ADNS  (Build  2)  structure  (see  Rehard  for  more  a  more  in  depth 
discussion  on  ADNS). 
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Figure  15.  ADNS  Block  for  CVN 
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Figure  16.  ADNS  Build  2  [JMCOMS] 


c.  Identifying  the  Role  of  the  Information  Managers  and  Commanders 
The  CINC  or  JTF  commander  is  responsible  for  providing  a  composite 
priorities  list  for  the  theater  to  resolve  priority  conflicts  in  their  AOR.  This  guidance, 
along  with  GBS  user  profile  inputs,  is  used  to  build  the  SBM  profiles  and  the  broadcast 
schedule.  The  TIM  serves  to  execute  the  responsibilities  of  the  CINC.  Thus,  the  TIM 
verifies  and  validates  user  requests  before  the  request  is  routed  to  the  information 
producer. 

The  model  has  a  slightly  different  implementation.  It  is  built  to  allow 
requests  to  go  directly  to  information  producers.  If  implemented  in  the  real  world,  this 
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functionality  assumes  that  the  TIM  has  coordinated  with  all  information  producers 
beforehand,  to  give  them  guidance  on  who  is  and  isn’t  allowed  to  access  information. 
This  process  keeps  the  responsibility  on  the  information  producer  to  produce  quality 
intelligence  and  provide  the  storage  and  meta-data  necessary  for  extremely  user-friendly 
operatoions.  Likewise,  placing  most  of  the  burden  on  the  “expert”  intelligence  producers 
(who  already  have  personnel  and  resources)  reduces  the  management  requirement  on  the 
GBS  SBM/TIM  and  reduces  GBS  caching  requirements. 

Nevertheless,  the  model  does  implement  the  TIM  by  building  an  “TIM 

ADNS  switch”.  The  ADNS  serves  to  push  products  to  the  GBS  only  when  the  GBS  is 

1 

the  best  cost  path f which  will  almost  always  be  the  case  if  the  GBS  is  operating  and 
enviroimiental  conditions  are  not  severely  degrading  the  broadcast).  It  is  the  author’s 
opinion  that  this  TIM  ADNS  switch  ideally  should  be  placed  at  a  NCTAMS-like  facility. 
Of  course,  the  facility  should  be  joint  and  not  “stovepiped”  like  the  existing  Service 
SATCOM  entry  sites.  Clearly,  the  TIM  functionality  goes  well  beyond  the  GBS  system 
and  should  strive  to  encompass  and  integrate  all  DoD  RF  communications  systems. 

d.  Identifying  the  Information  Producers  and  Products 
For  simplicity,  the  model  uses  one  entry  point/site  to  enter  the  DISN  for 
all  reach  back  channels  except  Challenge  Athena.  CA  uses  the  Naval  Computer  and 
Telecommimications  Station  (NCTS)  San  Diego  to  access  the  DISN.  Eight  types  of 
products  that  varied  in  size  were  able  to  be  requested  (see  Table  6).  However,  actual 
requests  only  came  from  two  of  the  six  nodes  shown  in  Figure  12.  One  of  the  nodes 
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represented  users  that  request  products  (via  HTTP  and  FTP)  such  as  imagery,  maps, 
briefs  and  documents.  The  second  node  represented  users  requesting  tactical  (e.g.,  order 
wire)  data  that  would  be  similar  to  tactical  intelligence  provided  by  the  Integrated 
Broadcast  Service  (IBS).  The  other  four  nodes  simply  are  placed  in  the  model  to  provide 
“background”  traffic.  Hence,  Email  generators  receive  the  same  packets  that  it  sends; 
likewise  for  the  message  traffic  node,  FTP  node  and  HTTP  node. 

In  reality,  it  should  be  noted  that  multiple  producers  can  simultaneously 
input  into  the  broadcast  and  expand  on  the  input  of  other  providers.  Some  examples  of 
providers  include  the  users  themselves  (possible  via  a  TIP)  or  anyone  with  access  to  the 
NIPRNET,  SIPRNET  or  JWICS.  [IBS]  Again  for  simplicity,  the  model  did  not 
incorporate  TIP  injection  and  provided  only  single  unicast  PIP  injection. 

Information  products  should  be  tagged  with  unique  reference  numbers  to 
allow  producers  and  users  to  correlate  the  products.  Thus,  the  user  can  readily  identify 
what  information  is  directly  from  the  producers/sensors,  what  information  is 
correlated/deconflicted  and  the  source  of  the  correlation/deconfliction.  [IBS]  An 
example  24  Mbps  configuration  for  one  transponder  is  shown  below  in  Table  9. 


Information  Product 

Channel 

Bandwidth  (Mbps) 

Program  Guide  and  Catalog 

1 

1 

CNN 

2 

3 

AFRTS 

3 

3 

Unclassified  Data 

4 

6 

Classified  Data 

5 

9 

Unused  Bandwidth 

- 

2 

Table  9.  Example  Single  Transponder  Broadcast  Allocation  [PACOM] 
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Data  examples  include  imagery,  weather,  maps,  ATO  (Air  Tasking  Order), 
and  the  MDU  (Mission  Data  Update).  Video  examples  include  UAV  video  and  virtual 
video-teleconferencing.  Appendix  J  provides  a  thorough  list  of  possible  GBS  products. 

e.  Implementing  the  GBS  SBM 

The  GBS  SBM  serves  to  carry  out  the  policies  from  the  TIM/CINC  in 
order  to  provide  the  best  service  to  users.  See  Chapter  III  CONOPS  for  more  detailed 
explanations  of  SBM  responsibilities.  In  building  the  program  guide  and  scheduling  the 
broadcast,  the  SBM  relies  on  having  updated  profiles.  It  is  very  critical  that  users  keep 
the  SBM/TIM  appraised  of  their  latest  information  needs.  This  is  especially  important 
when  dealing  with  smart  push  products.  The  model  connected  the  SBM  to  the  DISN  via 
the  SIPRNET  and  D-ATM  (DISN-ATM).  The  model  total  connectivity  for  Wahiawa  is 
40  Mbps  for  classified  data  and  14  Mbps  for  unclassified  data.  Table  10  shows  actual 
predicted  data  rates  for  the  three  GBS  SBMs. 


Wahiawa 

Norfolk 

Italy 

Secret 

40  . 

45 

40 

Unclass 

14 

25 

14 

Total 

54 

70 

54 

Table  10.  SBM  Port  Data  Rates  (Mbps)  for  GBS-DISN  Access  [Combs] 
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In  addition,  Figure  17  shows  the  actual  layout  of  the  PACOM  SBM  in 
Hawaii.  Building  261  provides  actual  connectivity  to  the  DISN  and  Building  108  houses 
the  SBM  and  MSS  gateway  equipment.  From  building  108,  the  broadcast  signal  is  sent 
to  the  PIP  for  transmit.  Due  to  the  focus  of  this  study  (on  reach  back  channels), 
limitations  of  the  modeling  program  and  time  constraints,  the  SBM  was  not  modeled  in 
as  much  detail  as  the  users  (ships),  the  reach  channels  and  the  communication  systems. 


S12kb3_ 


(EXISTING) 


FAST 

; ETHERNET 
I  100  BASE  F 


MULTIPLE 

512khff.i 


CIRCUITS 

(EXISTING) 


SIPRNET 

ROUTER 

(exLiting) 


NIPRNET 

POWERHUB 

ROUTER 

UNCLASS 

(eiLilinel 

POWERHUB 

SECRET 


ATM 

SWITCH 

SECRET 


SLI 1500 
SECRET 


^J^J-SEEialT 


ATM 

OC-3 


Figure  17.  GBS  Block  Diagram  -  Wahiawa^  HI 
[Combs] 


4.  Simulation  and  Data  Collection 

After  and  during  model  development,  an  analysis  plan  must  be  decided  upon.  To 
correctly  optimize  a  model,  only  one  factor  should  be  looked  at.  More  than  one  can  be 
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analyzed  if  the  factors  are  dependent  on  each  other.  The  model  in  this  thesis  focuses  on 
the  timeliness  of  the  messages.  Placing  time  stamp  attributes  at  various  sections  of  the 
model  allows  the  evaluation  of  timeliness  for  the  architecture.  A  similar  technique  can  be 
done  for  throughput  analysis.  As  already  mentioned,  Extend’ s  use  of  plotters,  timers  and 
“get  attributes”  blocks  take  up  considerable  memory  (See  Appendix  F).  One  “original” 
data  analysis  block  as  seen  in  Figure  12  used  twelve  Mbytes  of  memory.  If  one 
considers  that  the  thirteen  ships  and  the  four  major  category  of  information  requests  each 
have  this  data  analysis  node,  the  model  becomes  208  Mbytes  (not  including  the  rest  of  the 
model).  Figures  18  to  20  show  the  internal  blocks  of  a  data  analysis  block.  It  can  be 
seen  that  there  are  unlimited  data  areas  to  analyze.  However,  analysis  has  to  be  done 
piecemeal  (based  on  the  program  limitations)  unless  the  model  is  completely  rebuilt  to 
streamline  and  reduce  model  size.  It  should  be  noted  that  these  blocks  had  to  be  changed 
near  the  end  of  the  project  in  order  to  save  memory.  The  consequence  is  less  thorough 
data  collection  and  less  attribute  and  group  break  downs  for  later  detailed  analysis. 

Again,  this  project  concentrated  on  the  latency  of  the  request-to-receipt  cycle  for 
the  reach  back  channels  modeled  without  an  in  depth  look  at  each  channel.  As  such, 
thorough  model  variation  and  simulation  and  subsequent  sensitivity  analysis  was  beyond 
the  scope  of  this  project.  Nevertheless,  a  follow-on  researcher  can  use  the  model  to 
concentrate  on  one  or  more  reach  back  channels  to  obtain  more  detailed  performance 
results,  e.g.,  other  areas  such  as  throughput  and  channel  utilization  can  be  looked  at. 
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Figure  18.  Forward  Channel  Analysis 
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Figure  20.  Sample  Attribute  Analysis  Break  Down 
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Some  examples  of  sensitivity  analysis  include  changing  the  inputs  for  message 
rates  and  changing  MTUs  for  the  seven  reach  back  channels.  Another  recommended 
approach  or  tool  to  do  sensitivity  and  optimization  analyses  with  this  model  is  the 
orthogonal  array.  Orthogonal  arrays  provide  a  means  for  conducting  trade  and  system 
optimization  studies.  The  primary  steps  in  the  methodology  include: 

•  Brainstorming  to  define  factors  and  states 

•  Determining  the  objective  function  and  how  to  measure  it 

•  Setting  Up  the  Appropriate  Orthogonal  Matrix 

•  Running  the  Simulations 

•  Analyzing  the  results  [Roy] 

As  seen  in  the  data  analysis  figures,  data  can  be  collected  on  each  of  the  thirteen 
ships,  for  each  of  its  seven  reach  back  channels,,  for  each  of  its  eight  forward  channels, 
and  for  each  of  the  six  nodes  on  the  subnet.  Figure  20  shows  the  useful  attributes  that  can 
be  plotted  or  tabulated  in  a  table.  In  a  detailed  analysis,  plotters  would  be  strategically 
placed  in  the  data  analysis  blocks  to  look  specifically  at  certain  aspects  of  the 
communications  channel  or  architecture  model. 

This  project  collected  the  information  for  the  various  time  stamps  in  Figure  20  to 
calculate  request-to-receipt  times.  It  should  be  noted  that  to  account  for  SYN  and  ACK 
delays,  the  cumulative  propagation  distance  was  multiplied  by  a  factor  of  1.5  and  then 
divided  by  the  speed  of  propagation  (light).  The  result  is  added  to  the  model  end-to-end 
times.  The  SYN  and  ACK  delay  was  added  twice  (from  user  to  information  producer  and 
from  information  producer  back  to  the  user).  The  cumulative  propagation  distances  were 
zeroed  at  the  information  producers.  Thus,  the  actual  compensation  for  SYN  and  ACK  is 
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three  times  the  total  propagation  distance.  Table  11  provides  a  summary  of  the  data 
collected  from  one  simulation  (65  seconds).  Appendix  K  has  a  thorough  list  of  all 
attributes  and  time  stamp  values.  The  times  in  Table  1 1  are  not  actual  time  stamp  values 
as  indicated  in  Appendix  K,  but  are  relative  values  from  time  zero.  Hence,  the  times  for 
the  last  two  columns  give  an  indication  of  how  long  it  took  for  and  information  producer 
to  receive  a  request  and  how  long  it  took  for  the  entire  request-to-receipt  cycle.  Due  to 
time  constraints  and  severe  program  limitations,  some  ships  were  not  analyzed  arid  even 
some  that  were  analyzed  yielded  no  data. 


(seconds) 

Start  Time  Stamp 

Info  Producer 

End  Time  Stamp 

CV72 

0 

6.7430 

31.7495 

CG63 

0 

11.1477 

40.6999 

CG67 

0 

Not  Measured 

Not  Measured 

DDG65 

0 

2.0491 

14.0334 

DDG69 

0 

Not  Measured 

Not  Measured 

DD967 

0 

No  Data 

No  Data 

DD973 

0 

Not  Measured 

Not  Measured 

FFG48 

0 

Not  Data 

No  Data 

FFG51 

0 

Not  Measured 

Not  Measured 

AGE  10 

0 

No  Data 

No  Data 

SSN713 

0 

7.5431 

33.8458 

SSN716 

0 

Not  Measured 

Not  Measured 

SSN759 

0 

Not  Measured 

Not  Measured 

Tactical  Data 

0 

3.3601 

24.2962 

Imagery 

0 

7.0223 

27.422 

Word/PowrPt 

0 

.0578 

.7819 

Video/Audio 

0 

3.4930 

23.5802 

Table  11.  Time  Stamps  (Relative  Mean)  for  GBS  RB  Model 


5.  Data  Analysis 

As  mentioned,  the  key  parameter  analyzed  is  timeliness.  This  parameter  is  only 
one  (albeit  a  very  important  one)  of  many  that  should  be  taken  into  consideration  when 
developing  a  subsequent  GBS  IDM  process.  Throughput,  channel  utilization  and 
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information  relevance  are  some  other  key  parameters.  Information  relevance  is  a 
parameter  that  is  subjective  in  nature  and  would  not  be  an  easy  parameter  to  model. 
Instead,  information  relevance  should  be  analyzed  through  qualitative  research  of  past 
operations  and  exercises  and  associated  lessons  learned.  In  addition,  any  real  world  data 
from  initial  GBS  operations  should  be  studied  closely. 

As  discussed,  timeliness  can  be  studied  easily  with  different  techniques  in  Extend. 
This  project  chose  to  use  time  stamp  attributes  to  consolidate  analysis  of  the  information 
flow  to  the  very  end  of  the  model.  However,  the  drawback  to  this  approach  is  a 
significant  increase  in  model  size.  Other  Extend  approaches  include  the  insertion  of 
plotters  and  timers  at  focused  sections  of  the  model.  In  addition,  the  sensitivity  analysis 
feature  in  Extend  allows  a  user  to  vary  certain  parameters  automatically  for  multiple 
simulation  runs.  Tables  12  to  14  further  summarize  the  table  from  the  previous  section 
and  Appendix  K  and  were  intended  to  provide  timeliness  for  the  reach  back  channels 
modeled.  Unfortunately,  the  program  limitations  at  the  end  of  the  project  significantly 
curtailed  data  collection. 


(seconds) 

Total  Mean  Time 

Standard  Deviation 

Tactical  Data 

24.2962 

N/A 

Imagery/Mapping 

27.422 

15.0935 

Word  /  PowerPoint 

0.7819 

0.1672 

Video/Audio  Files 

23.5802 

N/A 

Table  12.  Round  Trip  Times  for  GBS  RB  Products 
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CV72 


CG63 


CG67 


DDG65 


DDG69 


DD967 


DD973 


FFG48 


FFG51 


AGE  10 


SSN713 


SSN716,  SSN759 


Total  Mean  Time 


31.7495 


40.6999 


Not  Measured 


14.0334 


Not  Measured 


No  Data 


Not  Measured 


No  Data 


Not  Measured 


No  Data 


33.8458 


Not  Measured 


Standard  Deviation 


10.7288 


20.2200 


N/A 


13.9618 


N/A 


N/A 


N/A 


N/A 


N/A 


N/A 


N/A 


N/A 


Table  13.  Ship  Round  Trip  Times  for  GBS  RB  Model 


Total  Mean  Time  I  Std.  Deviation 


SHF  Tactical  Data 


SHF  Imagery  * 


SHF  Word  /  PowerPoint  Files 


SHF  Video/Audio  Files 


CA  Tactical  Data 


CA  Imagery 


CA  Word  /  PowerPoint  Files 


CA  Video/Audio  Files 


Inmarsat  Tactical  Data 


Inmarsat  Imagery 


Inmarsat  Word  /  PowerPoint  Flies 


Inmarsat  Video/Audio  Files 


HF  Tactical  Data 


HF  Imagery 


HF  Word  /  PowerPoint  Files 


HF  Video/Audio  Files 


MSS  Tactical  Data 


MSS  Imagery 


MSS  Word  /  PowerPoint  Files 


MSS  Video/Audio  Files 


UHF  Tactical  Data 


UHF  Imagery 


UHF  Word  /  PowerPoint  Files 


UHF  Video/Audio  Files 


EHF  Tactical  Data 


EHF  Imagery 


EHF  Word  /  PowerPoint  Files 


EHF  Video/Audio  Files 


24.2962 


27.422 


N/A 


15.0935 


Table  14.  Round  Trip  Times  for  All  Back  Channels  for  GBS  Delivered  Products 
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V.  CONCLUSIONS 


A.  SUMMARY 

The  ideal  GBS IDM  architecture  should  work  like  the  IBS  vision:  GBS  should  be 
"an  integrated,  interactive  dissemination  system  which  provides  producers  and 
information  sources  the  means  to  disseminate  strategic,  operational  and  tactical 
intelligence  and  information  to  the  warfighter  via  multiple  transmission  paths  with 
dynamic,  user  generated  dissemination  priorities."  [IBS]  Thus  it  "incorporates  dynamic 
user  defined  prioritization  to  make  the  greatest  use  of  available  conununications 
bandwidth  and  obtain  the  best  operational  utility."  [IBS] 

This  vision  was  kept  in  mind  throughout  the  model  design  process.  As  such,  the 
model  strives  to  make  information  dissemination  via  GBS  as  transparent  as  possible  to 
the  user.  Implementing  reach  back  ensures  the  user  uses  information  in  the  same  manner 
as  the  growing  number  of  Internet  users.  Fiuthermore,  incoiporating  ADNS  at  both  the 
unit  level  and  at  the  communications  hub  (NCTAMS)  makes  the  model  architecture 
extremely  flexible  and  robust.  Likewise,  incorporating  a  GBS  CAP  at  the 
communications  hub  provides  another  alternative  and  automatic  means  of  pushing 
information  to  users.  This  seamless  integration  of  GBS  (using  reach  back  and  ADNS)  is 
significant  to  the  CINC  TIM  and  SBM’s  information  management  problem.  Therefore,  a 
one-way  system  virtually  works  as  a  two-way  system  and  the  GBS  bandwidth  is 
maximized  along  with  all  other  available  communications  channels. 
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With  these  implementations,  the  GBS  architectoe  can  get  away  from  the  smart 
push  and  user  pull  paradigm.  Instead,  all  broadcasts  can  emulate  a  “smart  pull”  concept. 
In  smart  pull,  the  information  can  be  considered  either  “pushed”  or  “pulled”.  If  pushed, 
the  user  interactively  selects  from  a  menu  of  pre-identified  GBS  broadcast  products  (at 
the  TIM  or  SBM  home  page).  The  action  of  selecting  a  product  sends  a  back  channel 
request  to  the  information  source.  The  information  provider  provides  the  product 
(assuming  that  the  TIM  has  told  the  provider  who  can  and  cannot  receive  their 
information)  to  the  GBS  SBM  via  the  TIM  ADNS  (located  at  NCTAMS).  If  there  is  any 
unusual  delay  or  unapproved  requests,  the  GBS  SBM  provides  the  user  feedback  via  the 
TIM  ADNS  and  non-GBS  communications  chaimels.  Otherwise,  the  information  is 
placed  on  the  GBS  broadcast  queue.  If  pulled,  the  only  difference  is  that  the  user 
interactively  selects  from  the  actual  information  producer’s  home  page  vice  the 
TIM/SBM  home  page.  Again,  a  significant  advantage  of  this  latter  method  is  the 
decreased  management  requirements  for  the  TIM.  ■ 

Hence,  the  “smart  pull”  concept  combines  the  two  types  of  information 
dissemination  into  one  mechanism  in  which  the  information  is  always  interactively 
requested  by  the  end  user  via  some  back  chaimel  method.  Hopefully  the  method  is 
automated,  even  for  users  that  are  not  fully  connected.  These  disadvantaged  users  could 
use  a  relay  approach  similar  to  the  HF  relay  in  the  model.  The  smart  pull  simplifies  the 
need  to  balance  smart  push  and  user  pull  because  the  user  is  “interactively”  requesting 
products,  regardless  of  whether  the  product  is  a  push  or  pull  item. 
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In  support  of  the  smart  pull  concept,  this  thesis  has  demonstrated  the  feasibility  of 
the  reach  back  mechanisms  in  an  environment  of  multiple  users  with  different  and 
multiple  reach  back  chaimels.  The  following  sections  summarize  the  advantages  and 
disadvantages  of  GBS  reach  back  and  highlight  the  usefulness  and  performance  of  each 
of  the  reach  back  channels  modeled. 

1.  General  Advantages  of  Reach  Back  for  User  Pull  Products 
Using  GBS  for  delivery  of  information  that  previously  was  disseminated  Over  the 
limited-throughput  tactical  links  reduces  the  overall  burden  on  the  tactical  channels  even 
though  additional  traffic  is  generated  by  reach  back  requests.  Often  times  these  tactical 
links  are  the  only  means  of  feedback  communication  for  users.  An  example  of  a  limited 
tactical  link  is  UHF  SATCOM,  a  communication  channel  that  many  lower  echelon  users 
must  rely  on  for  long-haul  communications.  Thus  with  RB,  the  lower  echelon  users  have 
increased  access  to  more  types  of  information  (when  policy  allows)  because  they  are  no 
longer  using  the  limited  tactical  channel  as  the  delivery  path,  but  rather  the  GBS. 

As  mentioned  previously,  reach  back  makes  GBS  an  end-to-end  system  and 
allows  users  to  participate  interactively  in  broadcast  scheduling.  The  ability  to  make. 
GBS  work  end-to-end  is  critical  to  end-users  because  the  users  cannot  provide  real-time 
feedback  on  information  requirements  without  RB  (this  is  especially  true  for  the 
disadvantaged  users).  In  general  a  disadvantaged  user  is  one  who  is  limited  in  the  ability 
to  use  large  anteimas  and  is  often  highly  mobile.  If  users  have  reach  back,  they  can 
inform  information  producers  and  broadcast  managers  that  they  need  old  information  to 
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be  rebroadcast  or  that  they  need  new  information  not  originally  broadcast.  As  a  result, 
GBS  reach  back  allows  users  to  tailor  the  broadcast  information  to  meet  dynamic  mission 
requirements. 

Additionally,  with  reach  back  an  end  user  is  more  likely  to  get  relevant 
information  because  the  user  is  interactively  requesting  the  information.  This  decreases 
the  risk  of  information  overload.  For  example,  how  often  do  people  miss  a  good 
television  show  because  they  were  too  busy  doing  day-to-day  activities?  For  the  warrior, 
the  term  is  “too  busy  putting  out  fires.”  It  is  not  a  situation  where  people  did  not  want  to 
watch  the  TV  show  or  the  warrior  did  not  need  the  information,  but  it’s  a  case  of 
forgetting  or  not  knowing  the  information  is  available.  Reach  back  inherently  ensures  a 
higher  probability  of  information  relevancy  to  the  end  user  because  the  action  of 
requesting  information  serves  as  a  near  real-time  reminder  to  look  for  that  information. 

Direct  reach  back  to  information  producers  also  assists  in  reducing  the  SBM 
caching  requirements.  Information  is  sent  to  the  SBM  only  if  the  GBS  pipe  is  available 
and  the  information  producers  are  responsible  for  the  storage  of  products. 

Furthermore,  reach  back  can  be  monitored  and  audited  to  help  identify  user 
information  tendencies.  Thus,  the  RB  audit  assists  in  scheduling  future  smart  push 
products  which  further  reduces  the  burden  of  information  management  on  the  TIMs  and 
IMEs  (Information  Management  Elements).  As  the  broadcast  schedule  becomes 
populated  with  more  smart  push  products,  use  of  the  GBS  bandwidth  becomes  more 
efficient. 
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A  similar  consequence  of  providing  more  bandwidth  for  a  variable  IP  data 
channel  to  deliver  RB-user  pull  products  is  the  reduction  of  TIM  and  SBM  requirements 
for  scheduling  and  managing  the  GBS  broadcast.  Using  a  GBS  IP  data  channel  for  RB- 
WWW  browsing  on  a  military  network  (via  the  DISN)  capitalizes  on  the  interactive 
nature  of  requesting  and  getting  information.  It  should  be  noted  that  the  author  disagrees 
with  the  notion  that  web  browsing  occurs  when  a  user  selects  a  “smart  push”  product  (i.e., 
Email  mailing  lists,  news  broadcasts,  consumer  sale  notifications,  etc.).  “True”  web 
browsing  occurs  when  the  user  gets  real  time  responses  to  inputs  into  the  keyboard  (e.g., 
TCP/IP  applications  such  as  FTP  [file  transfer  protocol]  and  TELNET).  When  mailing 
lists,  news  broadcasts  or  sale  notifications  are  delivered  to  a  user’s  Email  program  or  web 
browser,  the  user  may  or  may  not  look  at  it  based  on  the  user’s  schedule  at  that  time. 
User  pull  IP  data  channels  are  desirable  to  the  user  because  it  fits  better  with  the  “nature” 
of  information  users.  Moreover,  the  technology  advancements  of  the  web  (e.g.,  IP 
switching)  are  revolutionizing  (in  months)  how  people  share  information.  RB  user  pull 
IP  channels  provide  the  best  position  to  leverage  off  the  commercial  technology 
advancements. 

Lastly,  even  though  reach  back  tends  to  decentralize  GBS  information  flow, 
commanders  still  have  resource  control  if  "information  dissemination  by  negation"  is 
used.  A  decentralized,  “IDM  by  negation  concept"  harnesses  the  full  power  of  technology 
and  lets  the  users  have  access  to  everything  that  their  allocated  bandwidth  permits. 
Commanders  can  restrict  user  access  based  on  the  latest  mission  priorities  and  subsequent 
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resoxarce  allocations.  The  centralized  approach  of  giving  users  access  (only  when 
requested  and  approved)  adds  delay  in  verification  and  validation.  This  delay  may 
prevent  users  from  getting  relevant  and  timely  information. 

2.  General  Disadvantages  of  Reach  Back  for  User  Pull  Products 

Reach  back  for  user  pull  is  an  inefficient  use  of  the  GBS  bandwidth  if  the  CINC 
has  a  priori  knowledge  of  the  end  users’  information  needs.  In  the  ideal  situation,  exactly 
the  right  information  is  identified  for  smart  push  and  all  the  users  get  exactly  what  they 
need  and  only  what  they  need.  However,  in  accordance  with  the  GBS  Joint  CONOPS, 
“the  user,  more  so  than  anyone  else,  knows  their  information  requirements,”  thus  it  is 
unrealistic  to  assume  the  CINC  has  a  priori  knowledge  of  all  user  information 
requirements.  Nevertheless,  given  that  generally  “user  pull”  is  less  efficient  than  “smart 
push,”  the  goal  should  be  to  maximize  the  smart  push  portion  of  the  GBS  broadcast, 
constrained  by  the  requirement  to  satisfy  the  user’s  changing  needs.  Thus,  a  user  pull 
portion  should  always  be  available  for  end  users  to  access  a  broad  range  of  information 
based  on  their  latest  requirements. 

Updated  user  profiles  help  the  CINC  have  a  priori  knowledge.  Hence,  if  the  users 
are  responsible  in  dynamically  updating  their  profiles,  the  TIMs  aggressive  in  their 
collection  of  profiles,  and  the  SBMs  efficient  in  building  and  disseminating  the  profiles, 
the  need  for  user  pull  via  reach  back  is  minimized  (possibly  to  extinction).  It  is  a 
significant  assumption,  however,  to  assume  that  user  profiles  and  filters  will  dynamically 
be  kept  up  to  date. 
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Large  volumes  of  reach  back  requests  from  many  users  cause  broadcast  queue 
delays  at  the  SBM  due  to  scaling  problems  associated  with  TCP/IP.  Just  like  the  Internet, 
the  GBS  asymmetric  network  can  accommodate  a  finite  number  of  users  before  it 
experiences  excessive  congestion  and  delay.  An  in-depth  analysis  of  this  scalability 
problem  is  required  to  fully  assess  how  the  users’  effective  throughput  changes  with 
increases  in  the  number  of  GBS  users.  The  model  in  this  thesis  provides  a  first  look  at 
this  problem. 

During  times  of  heavy  use  of  tactical  links,  there  is  a  danger  of  saturating  the 
already  oversubscribed  military  communications  channels  with  too  many  reach  back 
requests.  As  a  result,  these  channels  may  not  be  able  to  cope  with  even  small  amounts  of 
RB  requests.  A  solution  to  this  problem  is  already  inherent  in  the  request  for  information 
(RFI)  procedures.  Priorities  and  policy  prevent  RB  from  using  bandwidth  that  is  needed 
for  critical  communications.  The  model  in  this  project  incorporates  the  use  of  ADNS  and 
priorities  to  ensure  highest  priority  messages  get  transmitted  first. 

Lastly,  reach  back  decentralizes  control  of  communication  and  information 
resources  away  from  commanders  and  broadcast  managers.  In  accordance  with  the 
USACOM  (United  States  Atlantic  Command)  GBS  CONOPS  (draft),  the  “USACOM 
staff  and  the  in-theater  commander  are  in  the  best  positions  to  determine  warfighter 
information  needs”  therefore  the  TIM  is  the  central  coordination  point  for  the 
apportionment  and  use  of  GBS  resources.  This  viewpoint  definitely  contradicts  a 
decentralized  reach  back  environment  where  users  have  access  to  information  producers 
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(without  directly  going  through  the  TIM). 

3.  Reach  Back  Channel  Findings 

From  the  model,  subjective  and  objective  conclusions  can  be  made  based  on  the 
model  default  parameters  and  the  actual  back  channel  performances.  The  relative 
weighting  of  parameters  is  subjective,  but  the  timeliness  measures  are  objective  (except 
when  data  is  declared  inconclusive).  The  following  discussions  provide  overall 
conclusions  for  the  reach  back  channels  modeled. 

SHF:  Currently  the  SHF  communications  plans  are  extremely  rigid,  however  they 
do  have  slack  times  that  can  be  utilized  via  ADNS.  Likewise,  the  SHF  packages 
currently  have  little  or  no  extra  room  for  additional  channels.  In  this  sense,  SHF  is  not  an 
ideal  reach  back  channel  and  other  less  utilized  mediums  would  make  better  back 
chaimels.  However,  as  implemented  in  the  model,  if  an  ADNS  RF  management  system 
could  integrate  the  entire  SHF  allocation,  it’s  shared  use  will  lead  to  overall  improved 
information  dissemination.  The  model  showed  that  a  large  portion  of  the  traffic  was 
routed  through  SHF  because  of  its  large  relative  bandwidth  and  the  way  the  model’s 
ADNS  calculated  congestion  cost.  However,  no  improved  timeliness  for  SHF  routed  data 
was  noted. 

Challenge  Athena:  Just  as  in  SHF,  allocation  of  bandwidth  is  also  a  limitation  for 
using  CA  for  reach  back.  Yet,  just  as  it  is  prudent  to  set  aside  significant  bandwidth  for 
GBS  variable  IP  channels,  it  is  also  prudent  to  do  the  same  for  SHF  and  CA. 
Subsequently,  by  incorporating  a  CA  and  SHF  CAP  into  ADNS,  the  large  bandwidth  of 
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these  systems  can  be  utilized.  CA  should  have  also  captured  a  large  percentage  of  the 
model  message  traffic,  but  did  not.  More  analysis  and  troubleshooting  is  needed  to 
determine  the  cause. 

Inmarsat  B  (HSD):  Overall,  Inmarsat-B  (HSD)  is  a  good  candidate  for  GBS  reach 
back  channel  implementation.  Although  its  data  throughput  does  not  approach  that  of 
some  other  high  data  rate  satellite  systems  such  as  VS  AT,  it  provides  “modest”  high  data 
rates  for  many  applications  (including  video)  with  worldwide  seamless  coverage. 
Additionally,  its  cost  is  relatively  low;  it  is  easy  to  employ,  and  it  is  extremely  portable 
(weighing  only  a  fi’action  of  other  high  data  rate  satellite  systems).  Its  main  drawbacks  is 
that  it  cannot  provide  real  time  video  due  to  the  64  kbps  channel  restriction,  but  must  rely 
on  a  store  and  forward  implementation  of  video  transmission.  As  a  result,  approximately 
30  minutes  of  delay  is  expected  from  live  video  to  remote  broadcast.  Additionally,  its 
most  efficient  use  relies  on  implementation  of  a  terrestrial  ISDN  (or  Switched-56)  link. 
Without  the  terrestrial  link,  Inmarsat-B  (HSD)  is  reduced  to  only  mobile-to-mobile 
communications  which  significantly  reduce  throughput  and  application  potential.  The 
rnodel  surprisingly  showed  that  Inmarsat-B  is  a  very  capable  back  channel.  It  was- 
probably  second  to  SHF  in  being  the  most  used  RB  channel.  Likewise,  the  total  time  for 
the  request  to  receipt  cycle  was  not  significantly  different  firom  higher  bandwidth  systems 
such  as  SHF. 

HF:  Even  though  the  Internet  can  provide  a  wealth  of  informa,tion  to  the 
warfighter  at  delivery  speeds  greater  than  ever  before,  the  limiting  factor  is  still  access. 
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As  such,  the  Chief  of  Naval  Operations  directed  that  all  USN  ships  have  full  Internet  and 
Email  capability  by  the  year  2000.  Yet,  where  does  all  this  capability  come  from? 
Existing  SATCOM  is  already  oversubscribed  and  future  systems  are  surely  to  be 
insufficient  compared  to  the  exponentially  increasing  bandwidth  requirements.  Using 
GBS  as  the  forward  link  and  HE  communications  as  the  back  channel  for  an  “Internet 
architecture  at  sea”  was  worth  researching  in  order  to  relieve  the  oversubscribed  satellite 
systems. 

A  HF  link  can  provide  sufficient  data  rates  for  a  GBS  back  reach  channel.  The 

link  is  greatly  affected  by  fading,  but  performance  greater  then  10~^  can  be  maintained 
through  the  use  of  spectrally  efficient  and  high  performance  modulation  techniques.  But 
modulation  techniques  alone  will  not  provide  enough  performance  to  maintain  a 

probability  of  bit  errorless  than  10“^ .  There  must  also  be  some  form  of  error  correction 
coding.  FECs  provide  additional  coding  gain  that  allows  sufficient  link  margin  to  meet 
performance  requirements. 

The  cost  of  additional  coding  gain  is  a  reduction  in  available  bandwidth  or  data 
rate.  Using  greater  convolutional  constraint  lengths  or  concatenated  codes  will  provide 
greater  coding  gain,  but  will  also  increase  circuit  complexity  and  lower  bandwidth. 
Experimental  tests  have  confirmed  HF  can  deliver  a  data  rate  ranging  form  2.4  to  75  kbps 
at  a  range  of  500  to  less  the  50  nm  respectively.  As  discussed  earlier,  three  possible 
methods  can  be  employed  to  increase  these  bit  rates. 

•  Using  multicarrier  techniques. 
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•  Develop  an  MC  with  the  capability  to  test  the  channel,  assign  available  HF 
radios,  and  dynamically  allocate  the  HF  bandwidth. 

•  Allow  the  MC  to  dynamically  assign  different  FEC  types  and  constraint 
lengths.  Thus,  there  will  be  enough  coding  gain  to  maintain  the  desired  link 
margin  while  minimizing  the  impact  on  the  available  data  rate. 

Therefore,  with  no  alterations  to  the  current  shipboard  systems,  HF  can  provide  a 
GBS  reach  back  channel  with  medium  data  capability.  With  minimum  alterations,  the 
shipboard  system  data  rates  can  be  improved.  HF  is  by  hot  a  total  solution  to  the  GBS 
reach  back  problem,  but  can  help  reduce  the  current  demands  on  SHF  links. 

Likewise,  the  model  effectively  showed  that  HF  provides  minimum  latency  due  to 
the  relative  short  link  distances.  The  use  of  HF  relay  was  a  great  path  for  smaller, 
disadvantaged  ships  to  transmit  reach  back  requests.  It  was  also  observed  that  the  use  of 
HF  relay  was  a  significant  factor  in  keeping  the  more  disadvantaged  ships  from  tying  up 
their  UHF  and  EHF  channels.  The  carrier  had  no  problem  processing  the  other  ship’s  HF 
relays.  The  HF  channels  actually  were  the  third  most  used  RB  channel  in  the  model.  In 
many  cases  the  HF  RB  was  easily  identified  by  it’s  quick  delivery  to  the  information 
producer. 

MSS  (Iridium):  Iridium  brings  another  exciting  opportunity  to  leverage 
commercial  satellite  technology.  As  a  reach  back  channel  for  GBS,  the  obvious 
advantage  of  the  system  is  it’s  low  latency  cross-linked  LEO  satellites.  However,  system 
data  rate  (2.4  kbps)  limits  the  ability  to  handle  large-sized  requests.  The  model  showed 
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that  a  small  percentage  of  the  reach  back  traffic  passed  through  the  system,  however  the 
datagrams  that  did  get  routed  through  Iridium  had  improved  timeliness  over  other 
channels  of  same  capacity. 

UHF:  UHF  DAMA  gets  the  high  marks  as  a  back  channel  due  to  its  coverage 
and  accessibility.  However,  it  ranks  average  for  throughput  (up  to  16  kbps  for  25  kHz 
and  4.8  kbps  for  5  kHz),  capacity,  and  security.  The  biggest  problem  in  using  UHF 
DAMA  for  a  back  channel  is  its  long  latency  (averaging  4.6  seconds  for  25kHz  and  27 
seconds  for  5  kHz  UHF  DAMA).  This  large  delay  problem  is  pointed  out  in  [Arthur],  but 
it  also  can  be  alleviated  through  the  CRIU  in  ADNS.  The  model  severely  underutilized 
the  UHF  RB.  Further  analysis  and  troubleshooting  is  required  to  find  the  problem. 

EHF:  Using  EHF  as  a  reach  back  channel  in  the  GBS  architecture  is  favorable  for 
many  reasons.  EHF  has  the  obvious  advantages  in  security.  Also,  because  EHF  is 
transmitted  using  LPI/LPD  spread  spectrum  techniques,  it  becomes  even  more  critical 
and  advantageous  to  use  during  wartime.  Additionally,  because  the  payload  processes  the 
incoming  signals,  any  anti-jam  (AJ)  is  filtered  out  before  transmitting  back  to  earth, 
niaking  EHF  communications  links  very  AJ  resistance.  The  narrow  beamwidth  at  these 
frequencies  also  makes  jamming  more  difficult.  This  channel  was  not  required  because 
the  other  model  channels  were  able  to  handle  the  default  settings  for  message  rates. 
Further  analysis  is  required  to  assess  the  effectiveness  of  EHF  LDR  as  a  reach  back 
channel.  The  model  showed  that  EHF  was  a  superb  RB  channel  for  its  capacity.  No 
significant  delays  were  noticed  for  products  that  were  requested  by  EHF. 
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B.  RECOMMENDATIONS  AND  AREAS  FOR  FURTHER  STUDY 

The  concept  of  "smart  push"  is  understandably  the  most  nahiral  way  to  use  the 
GBS.  Yet,  to  rely  on  a  majority  of  “smart  push”  dangerously  gets  into  an  increased  risk 
of  information  overload.  For  this  project,  this  overload  situation  can  be  represented  by 
increased  congestion  and  collisions  in  the  subnet.  This  project  did  not  inject  (push) 
information  to  user  subnets  unless  the  users  requested  the  information;  however,  one  can 
imagine  what  happens  when  introducing  a  large  amount  of  data  into  the  user  subnets.  If 
this  data  was  not  “recently”  asked  for,  but  rather  placed  in  an  “acceptance  profile”  days, 
weeks  or  months  before,  information  saturation  can  occur  quickly.  Even  without  smart 
push,  the  model’s,  percentage  of  entering  packets  that  experienced  collisions  was  around 
30%. 

As  such,  imless  there's  a  priori  knowledge  of  needs  and  the  user  has  a  complete 
imderstanding  of  the  products  being  disseminated,  data  never  transforms  into 
information.  As  discussed  previously,  implementing  reach  back  and  ADNS  into  the  GBS 
architecture  provides  an  opportunity  to  better  manage  the  system  if  one  uses  the  concept 
of  “information  dissemination  by  negation.”  In  this  concept,  the  TIM  still  maintains 
control  and  audits  all  GBS  information;  however,  no  direct  intervention  and  additional 
personnel  is  needed  to  ensure  the  maximum  use  of  scarce  resources.  By  reallocating 
more  GBS  bandwidth  to  variable  IP  channels,  the  TIM  has  the  ability  to  best  satisfy  users 
while  minimizing  the  intensive  challenges  of  theater  information  management. 
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1. 


Recommendations 


The  following  list  is  a  summary  of  recommendations  based  on  this  project: 

-  Improve  and  implement  reach  back  (asymmetric  networks)  into  the 
GBS  architecture  to  improve  xiser  access  to  information.  "The  ability 
to  win  the  Information  War  is  dependent  on  the  ability  to  provide 
critical  information  to  combatant  commands.  There  is  an  asymmetric 
flow  of  information  in  that  deployed  imits  normally  require  more 
information  for  mission  performance  than  is  required  for  return 
transmission.”  [IBS]  Lessons  learned  indicated  commanders  have 
historically  had  access  to  information  but  not  the  end  users.  As  such, 
the  priority  of  users  should  always  be  kept  in  mind.  GBS  should  not 
be  another  system  to  enhance  upper  echelon  users;  it  should  be  used 
first  to  provide  critical  information  to  disadvantaged  users. 

-  Continue  to  improve  the  information  on  military  networks.  Reach 
back  addresses  the  connectivity  to  get  information,  but  a  problem  that 
RB  does  not  solve  is  information  content  on  military.  Although  true 
for  the  Internet,  the  military  networks  (e.g.,  NIPRNET,  SIPRNET, 
Intelink,  and  NSANET)  have  significant  problems  with  poor  search 
capabilities,  unorganized  data  and  old  information.  The  producers  of 
information  must  be  accountable  for  keeping  web  pages  up  to  date  to 
make  GBS  reach  back  useful.  Otherwise,  the  “smart  push”  approach  is 
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the  best  method  in  organizing  the  information  on  military  networks. 
As  pointed  out  in  this  thesis,  however,  the  responsibility  to  provide 
good  information  should  not  be  placed  on  CINC  planners  and  users, 
but  the  information  producers. 

Incorporate  “smart  pull”  concepts  and  “information  dissemination  by 
negation.”  Initially,  the  GBS  pipe  will  be  underutilized,  as  was  the 
case  for  IBS.  This  period  is  the  time  to  test  out  these  concepts. 
Advertise  GBS  more  and  train  users.  One  reason  the  GBS  pipe  will  be 
underutilized  is  that  commanders  and  users  are  not  fully  cognizant  of 
GBS  capabilities.  Thus,  advertising  on  the  capabilities  of  the  GBS 
must  be  given  high  priority,  as  well  as  user  training.  Of  course,  the 
GBS  system  (like  most  new  technologies)  is  ahead  of  doctrine, 
therefore  it  is  critical  to  ensure  the  lessons  learned  from  operations, 
exercises  (such  as  JWID)  and  research  are  shared  with  all  GBS  users. 
Implement  ADNS  as  a  part  of  the  reach  back.  Dynamic  allocation  of 
RF  channels  is  a  natural  way  to  maximize  bandwidth.  It  is  projected 
that  ADNS  can  provide  a  four-fold  increase  in  throughput  during  peak 
traffic  times.  [Rehard]  Other  advantages  of  ADNS  include  the 
removal  of  humans  from  the  communication  loop,  the  ability  to  load 
share  between  channels  (ideal  for  naval  vessels  who  often  maintain  at 
least  two  operational  channels),  and  the  ability  of  units  with 
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uncommon  commimication  channels  to  maintain  communications. 
[Rehard] 

-  Incorporate  the  use  of  reach  back  relays.  The  relays  are  considerably 
important  for  less  capable  platforms  to  maintain  connectivity  with  the 
rest  of  the  fleet. 

-  Expand  the  role  of  HF  as  a  back  channel.  Refer  to  pages  70  -  74  of 
this  document. 

2.  Areas  for  Future  Study 

The  biggest  shortfall  of  this  project  was  the  underestimation  of  hardware  and 
software  limitations.  This  problem  caused  fi-equent  rework  due  to  abrupt  error  messages 
and  program  shut  down.  Program  failure  became  noticeable  when  the  model  size  was 
greater  than  40  Mb,  and  it  made  programming  impractical  after  50  Mb.  Beyond  70  Mb, 
the  program  would  accept  few  changes,  if  any,  before  it  abruptly  shut  down.  As  such,  an 
“on  the  job”  lesson  was  to  rebuild  the  model  to  be  less  than  50  Mb.  This  limitation 
severely  limited  the  analysis  that  could  be  performed  and  the  granularity  of  the  “right” 
side  of  the  model.  A  compromise  was  made  near  the  end  of  the  project  to  scale  down  the 
internal  composition  of  the  thirteen  ships  by  removing  the  data  analysis  blocks  (5  Mb 
each).  By  luck  the  author  was  able  to  incorporate  a  data  analysis  block  in  each  ship  type, 
however,  this  caused  the  program  to  act  very  sluggishly.  The  net  size  of  the  model 
became  1 02  Mb.  At  this  size,  a  50-second  simulation  would  take  almost  an  hour. 

Due  to  the  problems  associated  with  this  project.  Numerous  areas  of  study  can  be 
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looked  at.  Specifically,  the  program  problem  may  not  be  in  the  software  itself. 
Interesting  research  would  observe  how  the  model  operates  on  a  128Mb  RAM  machine. 
Furthermore,  an  analysis  on  the  impact  of  ADNS  was  not  done  due  to  time  constraints.  A 
simple  method  to  study  ADNS  would  be  to  equalize  the  “cost  congestion”  algorithm  so 
that  all  channels  have  the  same  chance  of  carrying  traffic.  In  the  default  model,  the 
bigger  channels  get  a  majority  of  the  traffic  due  to  their  bandwidth. 

Some  other  areas  for  future  study  are  highlighted  as  follows: 

-  Validate  and  improve  the  model  based  on  the  latest  lessons  learned  and 
technology  advancements.  For  example,  the  actual  GBS  flow  goes 
from  the  entry  sites  to  the  SBM/TIM  and  then  back  to  the  SBM.  This 
information  flow  was  not  developed  to  simplify  the  model  but  could 
be  done  as  future  research.  Likewise,  it  was  the  author’s  intention  to 
provide  the  smart  push  path  flow  into  the  model.  Due  to  time 
constraints  the  development  of  users  (ships)  was  built  to  accept  push 
data,  but  no  node  was  built  to  inject  the  data. 

-  Integrate  real  time  or  near  real  time  voice  and  video  (e.g.,  VTC)  users 
into  the  ships.  Previous  NPS  research  incorporated  VTC  in  an  IT-21 
model  using  both  Extend  and  OPNET  (see  Rieffer). 

-  Continue  detailed  model  analysis.  The  model  in  this  project  is  very 
robust  and  many  variations  of  numerous  parameters  were  beyond  the 
scope  of  this  project.  Focused  studies  based  on  specific  reach  back 
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channels,  users,  or  other  groupings  of  interest  can  be  done  as  follow-on 
projects. 

Conduct  studies  on  other  measures  of  effectiveness/measures  of 
performance  (MOEs/MOPs),  e.g.,  throughput  and  channel  utilization. 
Conduct  detailed  comparisons  on  the  GBS  performance  based  on 
existing  and  developing  protocols.  One  recommended  study  could 
look  at  the  effects  of  path  MTU  on  timeliness  and  effective 
throughput.  See  Appendix  I  for  default  MTU  settings. 

-  Conduct  a  similar  study  involving  other  AORs  and  possibly  include  a 
MTW.  In  addition,  the  study  could  build  a  second  model  which 
involves  an  Amphibious  Readiness  Group  (ARG)  and  a  Marine 
Expeditionary  Unit  (MEU)  conducting  an  military  operation  other- 
than-war  (MOOTW)  in  the  Pacific  AOR.  The  scenario  can  replace  the 
carrier  with  an  amphibious  assault  ship  (LHD),  add  one  LPD,  LSD 
and  MEU  ashore  (with  wireless  LAN)  and  keep  two  DDGs.  Recent 
NPS  work  uses  Extend  to  model  a  wireless  LAN  in  an  Operational 
Maneuver  From  the  Sea  (OMFTS)  network  [Smith]. 

Develop  a  GBS  IDM  process  template  to  incorporate  actual  IBS 
architecture  visions  by  applying  the  model  in  this  project.  This  work 
would  include  how  to  determine  the  best  mix  of  smart  push  and  user 
pull  by  comparing  the  results  of  model  variations.  Specifically,  the 
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variations  involving  different  amounts  of  user  pull  (reach  back) 
implementations  (e.g.,  no  user  pull,  25%  user  pull,  75%  user  pull  and 
100%  user  pull).  Likewise,  a  study  on  variable  allocations  of  GBS  IP 
channel  could  be  done.  For  instance,  this  model  used  15  Mbps  as  a 
default  value;  what  happens  if  this  value  is  more  or  less? 
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APPENDIX  A.  GBS  PHASE  II  CONFIGURATIONS  [ACOM] 


PIP-Only  Configuration,  PIP  and  TIP  Configuration,  PIP  and  Two  TIP  Configuration 
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APPENDIX  B.  REACH  BACK  CONNECTIVITY  MODES  [GBS] 


1 .  User  Pull  empowers  users  to  deal  directly  with  information  producers  using  existing 

procedures  to  request  information.  The  mode  used  to  make  the  request  depends  on  the  user’s  GBS  receive 
suite  connectivity  capabilities  and  the  user's  access  to  existing  information  systems.  Use  of  receive  suite 
feedback  from  terminals  which  are  either  fully  or  partially  connected  to  provide  quality  of  service  feedback 
to  the  SBM  will  improve  broadcast  efficiencies,  even  if  only  a  few  representative  terminals  can  act  as 
proxies  for  others  in  the  area  of  broadcast  beams. 

a.  Receive  Only  (RO)  Mode.  In  this  mode,  the  receive  suite  can  only  receive  the  GBS 

broadcast.  There  is  no  manual  or  automatic  communications  channel  available.  In  this  case,  the  user  has  no 
means  to  request  products  to  initiate  User  Pull. 

b.  Manually  Connected  (MC)  Mode.  In  this  mode,  the  receive  suite  can  receive  the 

GBS  broadcast  and  the  end  user  has  access  to  some  type  of  manual  communications  system,  A  human-in- 
the-loop  is  required  for  submitting  user  pull  requests  or  requesting  the  rebroadcast  of  data  products.  In 
other  words,  the  user  calls  in  a  request  using  whatever  existing  communications  capability  is  available. 

c.  Partially  Connected  (PC)  Mode.  In  this  mode,  the  receive  suite  can  receive  the 

GBS  broadcast  and  provide  a  means  to  transmit  using  standard  protocols  and  applications,  user  pull  or 
rebroadcast  requests.  The  rebroadcast  requests  are  automatically  generated;  however,  full  virtual  duplex 
connectivity  is  not  achieved  and  user  pull  is  not  automatically  generated.  The  users  must  still  request  their 
products  from  the  source  by  whatever  means  are  available  to  them.  The  likelihood  that  the  users  are 
connected  to  some  existing  network  is  high  and  they  will  make  their  user  pull  requests  via  the  various 
applications  programs  they  have  access  to  (e.g.,  SIPRNET  and  INTELINK). 

d.  Fully  Connected  (FC)  Mode.  In  this  mode,  the  receive  suite  can  receive  the  GBS 

broadcast  and  a  "return"  channel  exists  over  which  rebroadcast  requests  are  transmitted  on  a  packet-per- 
packet  basis  using  split  protocols.  The  requests  are  automatically  generated  by  the  RBM  and  a  virtual  full- 
duplex  connectivity  is  achieved.  However,  user  pull  is  not  automatically  generated.  The  users  must  still 
request  their  products  from  the  source  by  whatever  means  are  available  to  them.  The  likelihood  that  the 
users  are  connected  to  some  existing  network  is  high  and  they  will  make  their  user  pull  requests  via  the 
various  applications  programs  they  have  access  to  (e.g.,  SIPRNET  and  INTELINK). 

2.  In  the  future,  we  hope  a  more  automated  user  pull  network  might  be  accessible  to  all  users  over  GCCS 
or  some  other  standard  application  that  will  simplify  the  user  pull  process. 
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APPENDIX  C.  IDM  SERVICES  [IDM,  Mowerey] 

This  appendix  discusses  the  IDM  services  of  information  awareness,  information  access,  information 
delivery,  and  information  dissemination  support  services  and  presents  an  architectural  framework  for 
providing  the  services.  The  roles  of  information  sources,  commanders,  and  users  are  not  distinct;  e.g., 
commanders  are  also  information  users. 


Information  Awareness 

•  Indexing  and  Advertisingservlces 
for  Information  producers 

•  Cafa/og  services  to  make  relevant 
information  known 

•  Search  services  to  find 
operationally  relevant  information 

information  Access 

•  Automated  repetitive  information 
retrieval  (Smart  User  Pul^ 

•  Aggregation  of  Userproff/esto 
improve  information  and 
communications  resource  usage 

Information  Delivery 

•  Delivery  planningseTv'ice  \o 
optimize  use  of  infrastructure 

•  Commanders'  Po//cyservice  to 
implement  policies  on  user  profiles 
and  infrastructure  resource  usage 

info  Dissemination  Support 

•  Common  directoriesfor  sources, 
commanders,  and  users 

•  Integration  with  Dllsecunfy 
management 

•  Schema  interoperability  across 
source,  catalog,  and  user  domains 

Information  awareness  interacts  with  sources  to  populate  a  catalog  of  relevant  information,  and  makes  the 
catalog  available  to  users  in  accordance  with  commanders’  policies.  The  catalog  is  populated  by  either 
advertising  entries  or  by  search  and  discovery,  as  determined  by  the  capabilities  and  procedures  of  the 
associated  sources.  The  entries  in  the  catalog  are  built  upon  a  common  schema  structure  that  is  understood 
across  source  and  user  domains.  The  catalog  is  published  and  delivered  to  users  with  visibility  to  entries  in 
accordance  with  commanders’  policies.  The  catalog  is  accessible  by  either  a  user  display  or  by  electronic 
access  directly  from  user  mission  applications. 

Information  access  interacts  with  commanders  for  expression  of  their  policies  on  user  access  to  information 
and  the  allocation  of  infrastructure  resources,  with  sources  who  enable  access,  and  with  users  to  input  their 
information  requirement  profiles.  The  status  of  the  infoimation  distribution  infrastructure  (communications 
and  storage)  is  available  to  assist  commanders  in  dynamic  priority  adjustments  during  mission  execution. 
User  expression  of  information  requirements  (profiles)  is  either  through  an  interactive  user  interface  or  by 
direct  electronic  interface  from  user  mission  applications.  Overlaps  among  profiles  are  processed  by 
aggregation  of  similar  requirements  to  minimize  dissemination  of  duplicate  information.  User  profiles  will 
also  be.  provided  to  sources  to  assist  in  focusing  their  resources  on  specified  user  requirements  and 
priorities. 

Information  delivery  interacts  with  sources  to  support  the  retrieval  of  information  in  accordance  with 
validated  profiles,  with  the  information  distribution  infrastructure  to  optimize  information  transfer  in 
accordance  with  commanders’  policies,  and  with  users  in  the  delivery  of  information.  The  retrieval  process 
includes  translation  of  queries  and  data  formats  (mediation)  if  required  to  accommodate  inconsistencies 
between  source  and  user  systems.  Delivery  processes  located  at  sources,  at  intermediate  waypoints  within 
the  infrastructure,  and  at  user  sites  collaborate  to  develop  dynamic  path  selection  plans.  Monitoring  of  the 
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status  of  resources  within  the  infrastructure  provides  feedback  to  commanders  in  making  priority 
adjustments,  and  is  used  to  tune  and  optimize  delivery  plan  execution  based  on  changing  operational 
conditions.  The  delivery  path  may  differ  depending  on  factors  such  as  direction  and  amount  of  data  (e.g., 
requests  for  imagery  may  go  through  a  low-bandwidth  channel,  and  the  imagery  itself  may  be  broadcast 
via  GBS).  The  infrastructure  should  support  mechanisms  to  optimize  the  use  of  bandwidth  (e.g., 
multicasting). 

Information  dissemination  support  provides  the  necessary  interfaces  to  directory,  security,  operations,  and 
schema  management  functions  within  the  DII  to  support  the  other  functions  of  IDM. 


Information  Dissemination 
Management 
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IDM  Services  Functional  Decomposition 


An  architectural  framework  for  the  IDM  services  is  shown  above.  Each  of  the  shaded  boxes  represents  a 
software  module  that  provides  one  or  more  of  the  functions.  These  modules  will  be  deployed  to  one  or 
more  locations  within  the  DII.  Some  modules,  particularly  those  that  provide  local  IDM  interfaces,  must  be 
collocated  with  the  sources,  commanders,  users,  and  infrastructure  components  to  provide  acceptable 
performance.  Other  modules,  particularly  those  in  the  center  of  the  figure  will  provide  IDM  support  within 
an  AOR  from  a  small  number  of  regional,  component,  and/or  task-force  locations.  The  arrows  represent 
interactions  between  the  common  modules  and  the  local  IDM  interface  modules;  internal  interactions 
between  the  common  modules  are  not  shown. 


Many  of  the  IDM  functions  discussed  above  are  at  least  partially  addressed  by  commercially  available 
products  and  from  the  BADD  ACTD,  BC2A,  and  other  programs. 
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APPENDIX  D.  CINC  GBS  CONOPS  (DRAFTS)  [PACOM,  ACOM,  EUCOM] 


CINCs  are  responsible  for  their  own  GBS  CONOPS  in  order  to  tailor  the  GBS  system  to  their  specific 
AOR  requirements,  CINC  policies,  apportionment,  etc.  The  following  sections  are  provided  for  reader 
reference  and  outline  the  USPACOM,  USACOM  and  USEUCOM  GBS  CONOPS  (Drafts)  as  they  apply  to 
this  thesis.  The  reader  is  reminded  that  the  outlines  contain  direct  content  from  each  draft  CONOPS  and  is 
merely  organized  by  the  author  for  the  reader’s  reference. 

United  States  Pacific  Command  (USPACOM);  It  is  the  author’s  opinion  that  the  USPACOM's  view  is  to 
implement  a  more  decentralized  control  of  the  GBS  which  allow  users  to  use  the  bandwidth  as  it's 
available.  The  TIM  will  attempt  to  use  existing  RFI  procedures  to  remedy  any  conflicts.  The 
USPACOM’s  CONOPS  focuses  primarily  on  GBS  Phase  II  (scheduled  to  last  until  FY  2009). 

a.  What  must  the  PACOM  GBS  do? 

Connect  into  the  existing  and  future  communications  architecture  through 
established  DISN  gateways  (when  practicable).  It  should  be  noted  that  GBS  is 
not  a  primary  means  for  distributing  critical  command  and  control  information. 
Provide  the  communications  “pipe”  to  support  the  asymmetric  flow  of  large 
volumes  of  video  and  data  from  national  and  theater  information  sources  to 
fixed,  in-transit,  and  deployed  forces. 

Conform  sensor-to-shooter  information  dissemination  to  “smart  push”  and  “user 
pull”  principles  in  order  to  prevent  user  saturation  from  information  overload. 

b.  How  does  the  PACOM  GBS  provide  information? 

Uses  an  end-to-end  information  loop,  beginning  at  the  information  source, 
ending  at  the  GBS  user,  and  returning  from  the  user  to  the  information  source 
via  user  pull  information  requests. 

Pre-determines  smart  push  products  based  on  inputs  to  the  TIM  from  HQ 
USCINCPAC,  its  component  and  subordinate  commands,  the  Services,  and 
other  unified  CINCs. 

Broadcasts  user  pull  products  in  response  to  ad  hoc  requests  from  GBS  users  at 
all  levels  of  command  and  force  size. 

Broadcasts  both  Smart  Push  and  User  Pull  products.  During  routine  operations, 
the  TIM  and  SBM  will  coordinate  with  information  producers  to  receive  and 
broadcast  previously  determined  Smart  Push  products.  The  SBM  will  develop 
and  broadcast  a  catalog  of  these  information  products  to  GBS  users,  who  may 
then  subscribe  via  alternate  communications  systems  to  receive,  or  “pull” 
selected  products.  The  TIM  and  SBM  will  also  support  User  Pull  by 
coordinating  with  information  producers  and  users  to  broadcast  information  not 
in  the  product  catalog.  The  SBM  will  develop  a  program  guide  to  inform  users 
when  Smart  Push  and  User  Pull  information  will  be  broadcast. 

Receives  information  products  via  the  DISN  at  the  SBMs,  for  SBM  processing 
.  and  transmission  via  the  PIPs  to  the  satellites. 

Implements  TIM  guidance  in  building  and  transmitting  the  GBS  broadcast  on  a 
daily  basis  via  the  SBM  and  PIP. 

c.  What  are  some  key  PACOM  GBS  requirements? 
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Co-location  of  the  Primary  Injection  Point  (PIP)  and  Satellite  Broadcast 
Management  (SBM).  Personnel  working  in  the  SBM/PIP  facility  are 
responsible  for  collecting,  packaging,  and  transmitting  GBS  information  to  the 
space  segment.  SBM  and  PIP  operations  comply  with  HQ  USCINCPAC 
Theater  Information  Management  (TIM)  guidance  and  direction. 

Capability  to  transmit  a  single  level  end-to-end  bulk  encrypted  signal  from 
inject  terminal  to  receive  terminal.  In  order  to  transmit  and  receive  information 
at  different  levels  of  security  and  releasability,  user  organizations  must  add 
additional  cryptographic  equipment  at  the  front  and  back  ends  of  the  inject  and 
receive  terminals. 

Capability  of  the  steerable  uplink  antenna  to  receive  GBS  information  from  up 
to  three  TIPs  at  a  time.  When  using  multiple  TIPs,  each  TIP  must  be  assigned  a 
separate  transponder  and  must  be  within  a  350  nm  diameter  of  each  other. 
Capability  of  the  UFO  GBS  payload  to  receive  and  broadcast  signals  from  up  to 
four  inject  terminals  simultaneously.  In  the  default  configuration,  the  UFO  GBS 
payload  broadcasts  information  from  only  the  PIP  and  one  TIP  at  any  given 
time. 

Different  receive  suites  configurations  fielded,  depending  on  user  requirements. 
Connection  of  GBS  receive  suites  to  local  area  workstations  and  networks  in 
order  to  provide  GBS  information  directly  to  the  end  user’s  workplace. 

What  are  some  key  PACOM  GBS  elements  for  successful  implementation? 

Development  of  GBS  CONOPS  for  respective  subordinate  commands  (USFK, 
United  States  Forces  Japan  (USFJ),  ALCOM,  and  Special  Operations  Command 
Pacific,  SOCPAC). 

Modification  of  information  and  broadcast  management  processes  based  on 
operational  experience  and  advances  in  commercial  technology.  Subordinate 
commands  also  forward  Smart  Push  information  requirements  to  the  HQ 
USCINCPAC  TIM. 

Consolidation  and  forwarding  of  user  profiles  to  the  HQ  USCINCPAC  TIM  and 
SBM.  Subordinate  commands  also  coordinate  directly  with  information 
producers  to  receive  new  information  products. 

Compliance  with  the  DoD  MILSATCOM  Architecture,  Joint  Chiefs  of  Staff 
Memorandum  Of  Policy  (MOP)  37,  “Military  Satellite  Communications 
Systems,”  dated  14  May  92,  for  satellite  resource  apportionment  and 
allocation.” 

Organization  of  TIM  functions  within  USPACOM  by  the  CINC  (i.e.,  providing 
direction,  guidance,  and  policy  for  the  operation  of  the  apportioned  GBS 
resources).  No  one  person  or  organization  has  the  expertise,  authority,  and 
manning  to  accomplish  all  the  TIM  functions  required.  Since  procedures  and 
systems  currently  exist  within  USPACOM  to  request  and  provide  information  to 
appropriate  users,  USCEMCPAC  will  fulfill  its  TIM  responsibilities  by  using 
existing  processes  and  forming  a  GBS  TIM  working  group  co-chaired  by  the  J2 
and  J3  directorates  and  composed  of  members  from  the  staff  directorates. 
Working  Group  members  represent  their  directorates’  functional  disciplines  in 
advocating  users’  requirements,  resolving  cross-functional  issues,  and 
determining  Smart  Push  information  products.  The  TIM  will  provide  overall 
policy,  priorities,  and  operational  requirements,  guidance,  and  direction  to 
ensure  a  smooth  flow  of  information  across  GBS.  Guidance  and  policy  will  be 
promulgated  by  the  J6  directorate.  Direction  will  include  managing  apportioned 
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resources;  directing  spot  beam  pointing;  and  approving  the  broadcast  schedule 
and  information  contents  in  support  of  all  users,  including  supporting  CINCs, 
allies,  and  coalition  partners  under  the  UFO  8  FOV.  As  such,  the  TIM  will 
prioritize  and  adjudicate  between  competing  requirements  from  all  CINCs, 
Services,  U.S.  agencies,  and  subordinate  commands. 

Identification  of  USPACOM  GBS  TIM  Working  Group  responsibilities.  These 
responsibilities  include  development  of  rationale  for  GBS  employment, 
guidance  and  direction  for  the  GBS  broadcast  (i.e.,  prevent  GBS  “log-jams”  and 
abuse  of  user  pull),  and  approval  of  restrictions  on  users’  access  (as  required).  In 
addition  the  TIM  reviews  and  approves  information  products  (for  inclusion  in 
the  GBS  broadcast  catalog),  determines  priorities  for  information  transmitted 
over  GBS,  and  reprioritizes  information  and  users  based  on  mission  needs. 
Likewise,  the  TIM  must  determine  what  data  to  remove  from  the  broadcast  if 
demand  for  GBS  resources  exceeds  bandwidth  allocation.  The  establishment  of 
priorities  by  the  TIM  will  dictate  which  users  will  be  serviced  first,  which 
products  will  be  transmitted  first,  and  which  areas  will  receive  coverage  first. 
Also,  the  TIM  will  resolve  conflicts  between  competing  users  and  supporting 
CINCs,  coordinate  user  pull  procedures,  coordinate  user  profiles  and  user 
access,  determine  releasability  to  coalition  partners,  prioritize  TIP  access  to 
UFO  8  (in  the  event  of  multiple  TIPs  requiring  broadcast  over  UFO  8), 
determine  USPACOM  requirements  for  UFO  10  GBS  resources,  and  resolve 
conflicts  between  competing  users  and  other  CINCs.  Initial  broadcasts  consist 
of  regularly  scheduled  smart  push  products  (as  determined  and  coordinated  in 
advance  by  the  HQ  USCINCPAC  TIM).  As  users  become  familiar  with  GBS 
capabilities  and  the  information  products  catalog  (developed  and  distributed  by 
the  SBM),  User  Pull  products  will  begin  populating  the  broadcast.  Users  will 
make  requests  directly  to  the  information  producers  subject  to  HQ  USCINCPAC 
policy.  Again,  GBS  will  rely  on  the  existing  DISN,  such  as  voice,  record,  and 
electronic  mail  systems,  for  User  Pull  requests. 

Assistance  from  the  HQ  USCINCPAC  staff  and  SBM  (to  find  products  and 
coordinate  with  information  sources)  for  the  delivery  and  broadcast  of 
information  from  the  PIP. 

Number  of  downlink  antenna  movements  per  day  dependent  on  operational 
requirements  and  the  geographic  dispersion  of  GBS  users. 

Location  of  the  UFO  8  SBM  in  Building  108  at  NCTAMS  Pacific.  The  SBM  is 
manned  24  hours  a  day  with  approximately  5  persons  per  shift,  and  responsible 
for  day-to-day  GBS  system  operation. 

Reliance  on  existing  (non-GBS)  communications  systems  (e.g.,  secure  and 
nonsecure  telephone/facsimile/electronic  mail,  voice  radio.  Automatic  Digital 
Information  Network  (AUTODIN)  messages,  and  Joint  Worldwide  Intelligence 
Communications  System  (JWICS),  Secure  Internet  Protocol  Router  Network 
(SIPRNET),  etc.)  for  users  to  “reach  back”  and  request  User  Pull  products  to  be 
broadcast. 

United  States  Atlantic  Command  (USACOM):_It  is  the  author’s  opinion  that  both  USACOM  and 

USEUCOM  exert  more  control  over  GBS  broadcasts  through  the  use  of  the  TIM  (than  USPACOM).  To 

these  two  commands,  the  TIM  plays  the  critical  role  in  ensuring  the  GBS  delivers  the  information  required, 
a.  What  must  the  GBS  do? 

Act  as  an  adjunct  to  the  MILSATCOM  system,  which  is  under  the  purview  of 
Joint  Chiefs  of  Staff  (JCS)  and  the  associated  Integrated  Communications 
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Database  (ICDB)  process.  CINCUSACOM  validates  user  requirements  in 
accordance  with  the  ICDB  process  for  GBS  services  and  monitors  access  to  the 
USACOM  AOR  broadcast. 

Recent  operational  experience  in  Southwest  Asia,  Haiti,  and  Bosnia  has  proven 
that  no  single  command,  control,  communications,  computers,  and  intelligence 
(C4I)  system  or  service  can  satisfy  all  of  the  joint  or  combined  C4I  requirements 
of  the  modem  tactical  warfighter. 

Mobile  forces  are  thereby  freed  from  restrictive,  large,  fixed  terminals  and  can 
now  receive  information  products  formerly  delivered  only  to  command  centers." 

b.  How  does  the  GBS  provide  information? 

The  TIM  is  a  central  feature  of  major  importance  to  USACOM,  It  is  within  the 
TIM  that  the  dissemination  of  information  to  USACOM  forces  via  GBS  is 
coordinated.  Direct  interfaces  with  numerous  information  repositories  are 
maintained  in  order  to  produce  specific  information  products  tailored  to  meet 
warfighter  requirements  using  both  Smart  Push  and  User  Pull  methodology. 
This  process  of  information  management  by  the  warfighter  for  the  warfighter 
ensures  that  theater  GBS  subscribers  have  access  to  tailored  information  that 
best  supports  their  mission. 

Dissemination  of  these  products  will  use  a  dynamic  mix  of  “Smart  Push”  and 
‘‘User  Pull”  to  satisfy  warfighter  information  requirements  most 
expeditiously..., The  Smart  Push  approach,  which  will  constitute  the  major 
portion  of  USACOM’s  GBS  support,  will  optimize  the  use  of  those  GBS 
broadcast  resources  apportioned  to  the  command  through  efficient  broadcast 
scheduling  geared  to  meet  warfighter  information  utility  and  timeliness 
requirements  across  the.  AOR.  User  Pull  services  will  enable  deployed 
warfighters  to  request  and  receive  specific  information  products  needed  to  meet 
ad  hoc  operational  requirements. 

The  broadcast  management  process  will  be  based  on  the  use  of  subscriber 
information  profiles  for  Smart  Push  in  combination  with  User  Pull  responses  to 
specific  requests  for  information  (RFI)  from  deployed  warfighters. 

It  places  specific  information  products  from  each  of  the  CINC’s  TIMs  in 
broadcast  time  slots  according  to  established  priorities.  The  broadcast  schedule 
is  based  on  the  broadcast  capacity  apportioned  to  each  CINC  and  the  priority  of 
the  various  information  products  to  be  broadcast.  The  initial  apportionment  of 
UFO  9  GBS  resources  for  Phase  2  GBS,  has  USACOM  and  U.S,  Southern 
Command  (USSOUTHCOM)  sharing  one  500-nm  spot  beam  capable  of  48 
Mbps  and  one  500-nm  spot  beam  capable  of  24  Mbps.  The  2,000-nm  1.544- 
Mbps  area  coverage  beam  is  apportioned  to  USEUCOM. 

Within  the  USACOM  AOR,  there  are  two  types  of  GBS  broadcasts,  regional 
and  theater,  that  originate  from  the  SBM/PIP  and  the  TIP,  respectively.... In 
addition,  a  separate  CONUS  regional  broadcast  using  a  leased  commercial  Ku 
transponder  will  originate  from  the  NCTAMS  LANT  Detachment  Hampton 
Roads  SBM  serving  forces  belonging  to  ail  CONUS  CINCs. 

Also,  close  coordination  is  required  between  the  TIP  and  the  SBM/PIP  to 
deconflict  competing  broadcasts  and  ensure  interference-free  operations. 

GBS  will  have  two  major  classes  of  service:  Smart  Push  and  User  Pull.  Smart 
Push  is  the  process  by  which  information  products  such  as  intelligence,  bulk 
imagery,  TOMAHAWK  MDUs,  operations  updates,  software  enhancements, 
etc.,  are  placed  on  the  broadcast  in  accordance  with  a  prearranged  schedule  or  as 
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updated  information  becomes  available.  The  USACOM  TIM  will  work  directly 
with  theater  users  to  determine  what  video  and  data  products  they  require..  The 
TIM  will  accommodate  user  needs  to  the  maximum  extent  possible  in 
accordance  with  established  USACOM/CJTF  priorities  while  matching 
available  resources  with  demand.  The  primary  goal  of  Smart  Push  is  to  meet  the 
majority  of  the  predictable  information  needs  of  the  users  within  the  USACOM 
AOR  through  this  class  of  service.  Management  of  Smart  Push  services  will  be 
handled  by  the  existing  chain  of  command  as  part  of  the  deliberate  planning 
process  using  the  user  profiles  within  the  GRAT.  The  Smart  Push  approach 
optimizes  the  employment  of  shared  GBS  resources  by  allowing  the  SBM  to 
construct  a  predictable  broadcast  schedule  by  integrating  the  Smart  Push 
requirements  from  each  CINC’s  TIM  being  supported  by  the  broadcast.  User 
Pull  is  designed  to  give  authorized  users  in  the  theater  direct  access  to 
information  both  inside  and  outside  the  theater.... This  method  allows  the  user  to 
request  a  certain  information  product  through  a  reachback  process.... This  class 
of  service  will  help  satisfy  the  remaining  information  requirements  that  could 
not  be  met  through  Smart  Push.  Management  of  User  Pull  within  the  USACOM 
AOR  involves  creating  an  environment  in  which  users  and  providers  interact 
based  on  user  access,  privileges,  and  priorities  assigned  by  the  USACOM  TIM. 
This  approach  uses  existing  communications  means,  in  concert  with  GBS,  to 
create  a  virtual  two-way  network  for  interaction.  User  Pull  is  not  intended  to 
replace  existing  collection  management  processes.  In  many  instances,  RFI  and 
information  product  request  procedures  are  already  established  within  existing 
doctrine  and  policy.  For  GBS  purposes,  these  procedures  should  be  modified  as 
necessary  to  ensure  that  the  USACOM  TIM  is  advised  of  all  RFI  to  be  satisfied 
using  the  GBS  User  Pull  process. 

There  are  two  primary  types  of  broadcast  information  products:  video  and  data. 
Assured  delivery  of  data  products  is  not  possible  with  a  one-way  broadcast  such 
as  GBS;  however,  GBS  Phase  2  broadcasts  will  be  very  high  quality  (bit  error 
rate  (BER)  of  10’'°). 

Reachback  connectivity,  via  other  communications  means  that  GBS  can  provide 
specific  product  access  by  users.  This  reachback  capability  allows  a  user  to 
request  specific  and  timely  information  from  the  TIM.  The  TIM  will  have  a 
dial-in  and  a  SATCOM  link  interface  capability  to  allow  users  to  access  the  TIM 
gateway  server.  After  gaining  access  to  the  server,  users  can  browse  through  the 
TIM  homepage  or  the  menus  of  the  SIPRNET  or  Nonsecure  Internet  Protocol 
Routing  Network  (NIPRNET).  When  an  information  product  is  located,  the 
user  will  select  a  broadcast-delivery  option  to  determine  whether  a  single  user  or 
multiple  users  will  receive  the  product. 

The  high  bandwidth  of  GBS  allows  for  the  transmission  of  many  information 
products.  Therefore,  a  method  is  being  developed  to  screen  out  unwanted 
information  products,  using  filtering  and  buffering  mechanisms. 

Since  the  USACOM  staff  and  the  in-theater  commander  are  in  the  best  positions 
to  determine  warfighter  information  needs,  coordination  of  AOR  GBS  support 
by  the  TIM  enables  the  CINC  or  in-theater  commander  to  tailor  information 
services  and  optimize  the  flow  of  information  available  for  broadcast  to  the 
users  within  the  AOR. 

The  TIM  will  maximize  the  effectiveness  of  GBS  resources  within  the  AOR  by 
using  the  system  primarily  to  deliver  high-volume  information  products  by  the 
Smart  Push  distribution  process.  This  will  enable  the  off-loading  of  high- 
volume  information  products  from  other  LDR,  two-way,  C2,  SATCOM 


129 


systems.  The  TIM  will  also  coordinate  with  information  producers  about 
dissemination  of  information  products  developed  in  response  to  ad  hoc  user 
RFIs  under  the  User  Pull  provisions  of  GBS, 

To  take  advantage  of  the  high-speed,  high-bandwidth  properties  of  GBS,  the 
TIM  uses  the  following  factors  as  the  basis  for  deciding  which  information 
products  are  and  are  not  best  suited  for  dissemination  via  GBS:  size  of  the 
product,  new  or  existing  product,  number  of  intended  recipients,  location  of 
recipients,  delivery  timeliness  requirements  (precedence),  current  means  of 
delivery  (GBS  or  other),  availability  of  GBS-apportioned  resources,  &  ability  of 
recipients  to  accept  GBS  delivery. 

The  overarching  role  of  the  TIM  is  to  establish  and  monitor  USACOM’s 
policies  and  procedures  for  GBS  information  flow  within  the  AOR.  The 
USACOM  TIM  is  the  hub  for  managing  the  distribution  of  information  products 
to  meet  established  GBS  user  information  profiles  and  the  dissemination  of  data 
and  video  products  in  response  to  user  ad  hoc  RFIs. 

For  GBS  to  function  successfully  as  a  tool  for  theater  warfighters,  it  must  be 
controlled  by  the  warfighter. 

The  TIM  balances  user  demands  in  order  to  optimize  the  use  of  apportioned 
GBS  resources.  In  cases  where  demand  exceeds  the  availability  of  resources, 
the  TIM  will  reprioritize  information,  reallocate  bandwidth,  and  remove  low 
priority  information  products  from  the  broadcast.  In  addition,  the  affected  users 
are  notified  of  reprioritization  decisions.  When  requirements  call  for  additional 
GBS  resources  beyond  the  USACOM  apportionment,  the  TIM  can  request  the 
use  of  any  unused  resources  from  the  SBM  or  negotiate  with  another  CINC’s 
TIM  (i.e.,  USEUCOM)  to  borrow  GBS  resources. 

Due  to  the  limited  number  of  resources  in  the  GBS  Phase  2  architecture,  there 
will  always  be  more  CINCs  and  forces  requiring  support  than  available  GBS 
resources.  The  SBM  will  consolidate  these  requirements  with  requirements 
received  from  the  other  CINC  TIMs  and  produce  an  overall  broadcast  schedule. 
If  the  hot  spots  become  a  crisis,  the  TIM  may  allocate  more  resources  to  the 
CJTF  and  his  supporting  forces. 

The  GRAT  will  provide  the  TIM  with  the  capability  to  view  current  allocations 
and  usage  of  GBS  resources  and  the  means  for  monitoring  and  operational 
control  of  GBS  resource  utilization  throughout  the  AOR. 

The  USACOM  TIM  will  develop  and  maintain  catalogues  to  inform  users  of 
new  information  product  availability. 

Supported  by  SBM  traffic  analysis,  the  USACOM  TIM  will  audit  the  request 
process  used  for  User  Pull  to  preclude  abuse  and  logjams.  For  this  purpose,  the 
TIM  must  be  included  as  an  information  addressee  on  all  GBS  User  Pull  RFIs. 
This  will  enable  the  TIM  to  revise  decisions  concerning  user  access  and  Smart 
Push  GBS  content. 

Establishment  of  a  TIM  homepage  will  enable  remote  users  to  efficiently  access, 
browse,  and  request  information.  The  TIM  homepage  will  be  tailored  to 
provide  relevant  information  for  forces  conducting  operations  within  the 
USACOM  AOR.  Through  the  use  of  search  engines  on  the  homepage,  users 
will  be  able  to  locate  specific  items  of  interest  scattered  throughout  various 
disparate  information  repositories  more  quickly.  TIM  personnel  will  regularly 
update  the  resource  database. 

The  TIM  structure  supports  both  the  Smart  Push  preplanned  dissemination 
process  and  the  response  to  ad  hoc  User  Pull  requests  for  information 
products.... This  broadcast  schedule  is  developed  based  on  user  information 
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profiles  (Smart  Push)  and  specific  information  product  requests  (User  Pull). 
Within  the  USACOM  AOR,  the  TIM  will  be  an  addressee  on  all  requests  for 
GBS  information  products  from  USACOM  forces  and  will  attend  to  their 
satisfaction  in  accordance  within  established  priorities. 

It  is  envisioned  that  during  normal  peacetime  operations  within  the  USACOM 
AOR,  the  TIM  will  employ  the  Smart  Push  approach  for  the  majority  of  GBS. 
For  routine  delivery  of  high-volume  products  that  are  best  suited  for  high 
capacity  broadcast  delivery,  GBS  users  will  include  specified  products  on  their 
GBS  user  profiles  and  will  request  the  producer  organization  to  use  GBS  as  the 
delivery  medium.  As  such,  the  TIM  will  have  approval  authority  over  all  GBS 
use  by  units  operating  in  the  USACOM  AOR.  Therefore,  information  producers 
desiring  to  disseminate  their  product  via  GBS  will  need  TIM  concurrence. 

On  occasion  the  TIM  may  have  to  directly  interface  with  various  information 
sources  to  extract  data  and  build  tailored  information  products  in  response  to 
one-time  RFIs  from  GBS  subscribers  (i.e.,  User  Pull)  as  dictated  by  the 
operational/tactical  situation.  However,  with  adequate  planning  and 
development  of  comprehensive  GBS  subscriber  information  profiles,  this 
situation  should  rarely  happen,  most  probably  only  during  a  rapidly  developing 
crisis. 

Through  the  TIM,  USACOM  personnel  will  regularly  search  information 
sources  and  acquire  the  most  useful  information  products. 

To  facilitate  the  User  Pull  information  request  for  those  situations  where  users 
have  requirements  for  high  volume/wide  dissemination  of  unique  information 
products  not  contained  in  their  user  information  profile,  the  TIM  will  maintain  a 
system  of  product  catalogues  in  addition  to  maintaining  the  virtual  information 
resource  database... Users  will  submit  User  Pull  RFIs  via  other  two- 
way/reachback  communications  media. 

The  cornerstone  to  integrating  GBS  operations  is  the  consolidated  broadcast 
schedule.... To  construct  the  Atlantic  regional  GBS  broadcast,  the  SBM  will 
coordinate  with  the  various  producer  organizations  and  repositories  to  facilitate 
delivery  of  the  required  data  and  video  products  to  the  SBM  for  insertion  into 
the  broadcast  stream.... The  broadcast  stream  will  be  built  from  staged 
information  based  on  direction  received  from  each  CINC’s  TIM  that  identifies 
the  products  and  schedule  for  their  portion  of  the  broadcast.... While  it  is 
possible  that  files  may  be  corrupted  in  transmission,  the  GBS  system  BER  of  10' 
should  make  this  occurrence  extremely  rare. 

To  ensure  important  file  products  are  not  missed  following  payload 
configuration  changes,  hand-offs  between  TIPs  and  the  PIP,  or  spot  beam 
reorientation,  the  SBM  will  transmit  a  broadcast  synchronization  signal  and 
delay  the  transmission  of  information  to  the  new  coverage  area  for  a  period  of 
time  to  enable  users  to  acquire  and  synchronize  with  the  broadcast  downlink. 

c.  What  are  some  key  GBS  requirements? 

Since  only  three  UFO  satellites  will  be  equipped  with  the  GBS  Ka-band 
payloads,  the  continued  lease  of  commercial  satellite  services  in  the  Ku-band 
will  be  required  to  augment  UFO  GBS  coverage  over  the  continental  United 
States  where  coverage  gaps  exist. 

Multiplexing  equipment  at  the  PIP  will  allow  various  data  streams  to  be 
uplinked  on  various  channels  to  support  dynamic  requests  and  multiple  users. 

For  GBS  Phase  2,  only  one  TIP  will  be  capable  of  uplinking  data  to  the  GBS 
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satellite  at  any  one  time....USACOM  or  the  designated  CJTF  will  deconflict 
TIP  operations  when  multiple  TIPs  are  deployed  within  the  GBS  footprint  area 
by  assigning  specific  time  slots  to  each  in-theater  TIP.... Although  use  of  the 
TIP  can  offer  some  significant  advantages,  its  use  takes  a  dedicated  transponder 
away  from  the  regional  PIP  broadcast  and  use  of  the  TIP  near  front  lines  may 
subject  the  uplink  to  enemy  jamming. 

The  PIP  is  capable  of  uplinking  four  24-Mbps  video/data  streams  while  the  TIP 
is  limited  to  a  6-Mbps  uplink  capability. 

It  is  important  to  note  that  reconfiguration  of  the  GBS  transponders  to  uplink 
and  downlink  antennas  is  not  directly  controlled  by  the  SBM  since  it  requires 
,  use  of  satellite  control  telemetry,  tracking  and  commanding  (TT&C)  resources 
controlled  by  the  Air  Force  and  Navy  satellite  control  systems.... Likewise, 
while  spot  and  area  coverage  beams  can  be  repointed  under  TIM  direction  and 
SBM  control  to  direct  the  broadcast  streams  to  dispersed  users  throughout  the 
satellite  FOV,  the  process  is  not  instantaneous  and  can  take  up  to  10  minutes  for 
each  beam  movement. 

The  SBM  will  have  the  capability  to  remotely  enable  or  disable  receive  suite 
access  to  the  broadcast. 

The  SBM  will  maintain  end  user  profiles  (description  of  user  receive 
configuration,  product  requirements,  location,  CINC  priorities,  etc.)  to  enable 
,  development  of  Smart  Push  and  access  control. 

'  -  The  SBM  will  use  this  information  to  perform  traffic  analysis  and  provide  each 

j  of  the  supported  CINC’s  TIM  with  an  assessment  of  overall  broadcast 

utilization  and  how  well  information  is  flowing  over  their  apportioned  GBS 
resources. 

Most  RBM  functions  will  be  resident  in  the  receive  suite,  but  some  may  be 
located  with  end  user  equipment. 

d.  What  are  some  key  GBS  elements  for  successful  implementation? 


In  the  Atlantic  area  the  SBM  is  located  at  Naval  Computer  and 
Telecommunications  Area  Master  Station  Atlantic  (NCTAMS  LANT) 
Detachment  Hampton  Roads,  VA. 

The  GBS  user  base  is  expected  to  grow  rapidly  once  deployment  of  the  system 
begins  and  users  realize  the  potential  benefits  available  to  them.The  BADD 
system  is  being  developed  to  achieve  new  levels  in  managing  information 
access  and  flow. 

Tactical  information  on  air,  sea  or  land  units  is  available  for  COP  construction 
in  context  with  other  source  information  now  available  to  the  warfighter.  Raw 
information  enters  the  database  through  automated  channels  for  some  systems 
and  is  manually  entered  for  others. 


United  States  European  Command  (USEUCOM):  It  is  the  author’s  opinion  that  the  USEUCOM  CONOPS 
(draft)  is  nearly  identical  to  the  USPACOM  CONOPS  (draft).  As  such  the  following  outline  will  only 
include  selected  sections  that  varied  from  the  USACOM  CONOPS.  It’s  not  surprising  that  the  two 
CONOPS  are  very  similar  given  the  fact  that  they  will  have  to  share  the  use  of  the  UFO-9  satellite. 
Nevertheless,  the  author  also  notes  that  USEUCOM  has  adopted  similar  TIM  functions  and 
implementations  as  USPACOM. 
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a.  What  must  the  GBS  do? 


The  TIM  and  SBM  uses  subscriber  information  profiles  to  manage  Smart  Push 
and  anticipate  User  Pull  User  Pull  (RFI)  from  deployed  warfighters.  GBS  is  a 
one-way  broadcast  that  only  distributes  information,  requests  for  information  ( 
RFIs)  User  Pull  must  be  made  via  other  communications  means. 

The  GBS  is  a  multicast  system.  Multicast  allows  simultaneous  broadcast  of  a 
variety  of  data  and  video  products.  The  system  can  provide  these  products  to  all 
users,  a  small  subset  of  users,  or,  in  some  cases,  a  single  user  depending  on  how 
the  information  is  addressed  and/or  routed. 

This  request  link  uses  any  existing  Service-unique,  low-bandwidth 
communications  system  available  to  the  user  which  employs  Transmission 
Control  Protocol  (TCP)  and  Internet  Protocol  (IP)  routing  protocols. 

Since  the  USEUCOM  staff  and  the  in-theater  commander  determines  warfighter 
information  needs,  coordination  of  AOR  GBS  support  by  the  TIM  enables  the 
CINC  or  in-theater  commander  to  tailor  information  services  and  optimize  the 
flow  of  information  available  for  broadcast  to  the  users  within  the  AOR. 


b.  How  does  the  GBS  provide  information? 

The  Smart  Push  approach,  constitutes  the  major  portion  of  USEUCOM’s  GBS 
support,  optimizes  use  of  GBS  broadcast  resources  apportioned  to  the 
command  through  broadcast  scheduling  geared  for  warfighter  information 
utility  and  timeliness  requirements. 

Within  the  USEUCOM  AOR,  the  TIM  is  an  addressee,  or  the  lead  on  all 
requests  for  GBS  information  products  from  USEUCOM  forces  and  will  attend 
to  their  satisfaction  in  accordance  within  established  priorities.  Bottom  line,  the 
CINCs  priorities  will  drive  the  scheduling  of  product  delivery. 

USEUCOM  fulfills  all  USEUCOM  GBS  information  management 
responsibilities  through  the  HQ  USEUCOM  GBS  Information  Management 
Board  (GIMB),  co-chaired  by  the  J2,  J3  and  J6  and  composed  of  members  from 
the  staff  directorates.  As  GIMB  co-chairs,  the  J2,  J3  and  J6  are  responsible  for 
operational  requirements,  guidance,  and  direction  in  managing  USEUCOM 
GBS  operations.  Working  Group  members  will  represent  Iheir  directorates’ 
functional  disciplines  in  advocating  users’  requirements,  resolving  cross¬ 
functional  issues,  and  determining  Smart  Push  information  products. 

c.  What  are  some  key  GBS  requirements? 

Additionally,  to  support  JTF,  NAVEUR,  and  MARFOREUR,  GBS  also  requires 
an  interface  with  the  Joint  Maritime  Command  Information  System  (JMCIS). 
Remember,  this  is  a  broadcast  service  and  does  not  insure  delivery. 

The  TIP  and  PIP  DON’T  multiplex  on  the  satellite.  The  TIP  completely  uses 
one  of  the  transponders  on  the  satellite. 

d.  What  are  some  key  GBS  elements  for  successful  implementation? 
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Since  GBS  enables  the  storage,  retrieval,  and  dissemination  of  huge  information 
files  that  quickly  exceed  the  capability  of  most  mobile  users,  the  tailoring  of  the 
Smart  Push  and  User  Pull  dissemination  architecture  for  GBS  is  a  significant 
challenge  (see  section  2.3.2). 

The  500  nm  spot  beams  and  the  2000  nm  Broad  beam  on  UFO  9  will  be  shared 
by  TRANSCOM,  SOCOM,  STRATCOM  SPACOM,  USEUCOM, 
USSOUTHCOM,  and  USACOM. 

USEUCOM  J6  will  send  out  a  questionnaire  on  the  products  that  are  wanted  by 
the  users. 

USEUCOM  plans  on  updating  the  AOR  GBS  broadcast  schedule  at  least  every 
three  days.  USEUCOM  will  modify  it  in  response  to  operational  changes 
throughout  the  AOR  and  the  availability  of  GBS  resources  apportioned  to 
USEUCOM.  The  SBM  will  broadcast  a  consolidated  schedule  from 
USEUCOM’s,  USACOM’s,  USPACOM’s,  and  USCENTCOM’s  TIM.  ‘ 

USACOM  oversees  SBM  operations  for  UFO  9  and  USEUCOM  oversees  SBM 
operations  for  UFO  10  for  Joint  Staff. 

The  USEUCOM  SBM  will  be  funded  and  operated  by  the  Navy  at  Sigonella, 
Italy. 


Other  CINCs:  CONOPS  were  not  available  from  any  other  CINCs  prior  to  this  publication. 
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APPENDIX  E.  GROUND  RECEIVE  SUITE  FIELDING  AND 
CONFIGURATIONS  [ORD,  Chappell] 


1.  Army:  A  total  of  504  receive  suites  will  be  fielded  to  Force  Packages  I,  II,  and  III,  and  Force 
Support  Packages  I  and  II. 

2.  Navy:  Total  of  166  receive  suites,  of  which,  50  will  be  manpackable  receive  suites.  All  shore 
requirements  shall  be  met  by  2004. 

3.  Air  Force:  300.  The  Air  Force  may  require  additional  receive  suites  pending  the  outcome  of 
their  current  receive  suites  fielding  analysis. 

4.  USMC:  Estimated  total  of  70  receive  suites. 

**The  number  of  required  receive  suites  may  change  (increase  or  decrease)  pending  the  outcome 
of  fielding  analysis.  All  ship  and  submarine  requirements  should  be  equipped  by  FY  2004.  The 
services’  initial  plan  is  to  acquire  1,406  ashore,  afloat,  and  subsurface  receive  suites. 


FIXED 

Quantity 

Required 

NCTAMS 

10 

NCTS 

18 

COMMDET 

4 

MAST 

7 

MICFAC 

5 

TSC 

15 

MOC 

9 

CINC  CCC 

4 

TOTAL 

72 

TRANSPORTABLE 
MANPACKABLE  * 

Quantity 

Required 

SPECWAR  * 

50 

EODGRU 

20 

TACGRU 

10 

BEACHGRU 

10 

CINC-MOBILE 

4 

TOTAL 

94 

.  SHIP 
CLASS 

Quantity 

Required 

SHIP 

CLASS 

Quantity 

Required 

SHIP 

CLASS 

Quantity 

Required 

SHIP 

CLASS 

Quantity 

Required 

CVN 

10 

CG 

27 

MCS 

1 

TAE 

8 

CV 

3 

DDG 

.  50 

MCM 

10 

TAPS 

8 

AGF 

2 

DDG993 

4 

MHC 

11 

TAGOS 

8 

LCC 

2 

DD 

31 

AOE 

8 

TAH 

2 

LHA 

5 

FFG 

20 

AO 

5 

TAO 

12 

LHD 

7 

FFGNRF 

10 

ARS 

4 

TATF 

5 

LPD 

12 

SSN 

52 

AS 

3 

ISEA 

1 

LSD 

17 

SSBN 

14 

PC 

13 

TRAINER 

1 

TOTAL 

366 

Unit  Total 

Total 

SJTF 

1 

1 

MARFORPAC/MARFORLANT 

1  ea 

2 

MEF  Command  Element 

2  ea 

6 

Marine  Division  Command  Element 

2  ea 

6 

Marine  Division  Infantry/Artillery  Regt 

1  ea 

10 

MAW  Command  Element 

2  ea 

6 

MAW  MAG/Support  Group 

1  ea 

13 

FSSG  Command  Element 

2  ea 

6 

FSSG  Standing  CSSD 

I  ea 

6 

MEU 

1  ea 

7 

MCCES 

2 

2 

Marine  Reserve 

5 

5 

Total 

70 
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Ground  Receive  Suite  Configurations  and  Allocation-. 
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APPENDIX  F.  EXTEND  BLOCK  DEFINITIONS  [EXTEND] 


Activity,  Delay  Block.  Holds  an  item  for  a  specified  amount  of  delay  time,  then  releases  it. 
The  delay  time  is  the  value  in  the  dialog  or,  if  connected,  the  value  at  the  D  connector  when  the  item  is 
received  (the  connector  overrides  the  dialog).  This  block  can  be  used  for  any  kind  of  service  delay.  For 
example,  you  can  use  this  block  to  represent  red  lights  in  traffic,  the  time  it  takes  a  clerk  to  wait  on  a 
customer,  or  multitasking  CPU  time. 


Activity,  Delay  (Attributes).  Works  the  same  as  the  Activity  Delay  block  except  it  interacts 
with  an  item's  attributes.  You  can  use  the  attribute  value  as  the  delay  and/or  modify  the  attribute  value.  The 
delay  time  is  (in  order  of  decreasing  priority):  •  D  (delay)  connector  (if  it  is  connected);  •  the  value  of  the 
chosen  attribute  (if  that  option  is  selected  in  the  dialog);  •  the  delay  (time  units)  value  specified  in  the 
dialog.  If  you  are  using  an  attribute  value  as  the  delay,  you  can  specify  whether  the  first  attribute's  value  or 
a  named  attribute's  vhlue  is  used.  You  may  also  have  the  block  modify  an  attribute  value  (of  either  the  first 
or  a  named  attribute).  The  options  for  this  modification  include  subtracting  the  delay  used  from  the  chosen 
attribute,  increasing  the  attribute  value  by  a  percentage,  or  adding  a  specified  value  to  the  attribute.  The  A 
connector  overrides  the  percentage  or  value  for  modifying  the  attribute.  By  subtracting  the  actual  delay 
time  from  an  attribute,  you  can  later  determine  how  long  an  item  has  been  delayed.  For  example,  you  can 
use  this  block  to  process  (delay)  an  order  for  the  time  specified  by  its  attribute,  then  subtract  the  delay  from 
the  attribute  value  to  show  that  the  item  has  been  processed.  Or  you  could  process  an  item,  then  add  an 
amount  to  an  item's  attribute  to  track  processing  costs.  The  number  of  items  which  have  arrived  in  the 
block  and  the  number  that  have  departed  from  the  block  are  displayed. 


Activity,  Multiple.  Holds  many  items  and  passes  them  out  based  on  the  delay  and  arrival 
time  for  each  item.  The  item  with  the  smallest  delay  and  earliest  arrival  time  is  passed  out  first.  The  delay 
time  for  each  item  is  set  through  the  D  connector  or,  if  nothing  is  connected  there,  can  be  specified  in  the 
dialog.  For  example,  this  block  can  be  used  to  represent  a  supermarket  where  customers  arrive  at  different 
times  and  take  a  varying  amount  of  time  to  shop.  Customers  who  arrive  earlier  or  only  shop  a  little  will 
leave  first;  customers  who  arrive  later  or  shop  a  long  time  will  leave  last. 


Activity,  Service.  Passes  an  item  only  when  the  demand  connector  is  connected  and  certain 
conditions  exist  at  the  demand  input  (either  demand's  value  is  true  [greater  than  0.5]  or  it  pulls  in  an  item). 
Depending  on  the  type  of  output  connector  (item  or  value)  attached  to  demand,  this  block  passes  single 
items  or  passes  a  specified  number  of  items.  This  block  allows  service  on  demand.  You  can  think  of  this 
block  as  a  path  with  a  gate  that  opens  on  demand,  where  demand  can  accumulate.  If  an  item  output 
connector  is  attached  to  the  demand  connector,  the  block  accumulates  the  value  of  the  items  coming  into  it 
and  passes  that  many  items  through  (item  values  can  be  set  by  other  blocks,  for  example  the  Set  Value 
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block).  For  example,  if  an  item  with  a  value  of  4  is  passed  to  the  demand  connector,  the  block  will  pass 
four  items  through  before  closing  its  “gate.”  The  block  accumulates  demand:  two  items  at  the  demand 
connector  with  values  of  4  and  3  will  cause  this  block  to  accumulate  a  demand  for  7  items  at  its  item  input 
connector.  If  required  items  are  not  immediately  available,  the  block  will  remember  the  demand  amount 
and  decrement  it  only  as  items  become  available  and  are  pulled  in.  If  a  value  output  connector  is  attached 
to  the  demand  connector,  items  will  pass  through  as  long  as  the  value  at  demand  is  greater  than  0.5.  For 
example,  a  value  of  4  from  a  value  connector  will  cause  items  to  pass  through  the  block  as  long  as  the  gate 
is  open.  The  4  does  not  affect  the  number  of  items  passed,  it  only  serves  to  keep  the  gate  open.  If  the  value 
at  the  value  connector  changes  to  0,  the  gate  will  close.  This  block  serves  as  a  conditional  wait.  Examples 
are:  multiple  food  orders,  customers  waiting  in  line,  flight  arrivals.  Warning:  When  using  the  Activity 
Service  block  it  is  possible  to  prematurely  halt  the  flow  of  events  in  a  simulation.  This  can  occur  if  you 
have  a  resource  block  (for  example,  the  Resource  block  from  the  Discrete  Event  library,  or  Stock  or  Bin 
from  Manufacturing  library)  connected  to  an  Activity  Service  block,  and  the  Activity  Service  block  is 
controlled  by  an  Input  Data  block.  If  the  first  number  output  by  the  Input  Data  block  is  a  zero,  and  there  is 
no  other  source  of  events  in  the  model  (such  as  a  Generator  or  Program  block),  the  Executive  block  will  set 
the  time  clock  to  the  end  of  the  simulation  and  the  simulation  will  end.  A  simple  work-around  in  this 
situation  would  be  to  use  a  Program  block  to  control  the  Activity  Service  block  because  the  Program  block 
generates  its  own  events. 


Add.  This  block  adds  the  three  inputs  on  the  left  of  the  block  and  outputs  the  total. 


Batch.  Allows  items  from  several  sources  to  be  joined  as  a  single  item.  This  is  useful  for 
synchronizing  resources  and  combining  various  parts  of  a  job  (“kitting”).  In  the  dialog,  you  specify  the 
number  of  items  from  each  of  the  inputs  that  is  required  to  produce  one  output  item  (one  “kit”).  You  can 
also  specify  that  items  at  one  or  more  inputs  will  not  be  brought  into  the  block  until  one  or  more  of  the 
other  inputs  has  its  requirements  filled.  The  block  can  either  let  all  items  waiting  to  be  batched  into  the 
block  whenever  they  arrive  (the  default  mode),  or  can  force  the  items  at  specified  inputs  to  wait  outside  the 
block.  Each  input  for  which  "Delay  kit  at..."  is  selected  will  have  its  items  wait  outside  until  all  required 
items  for  the  unselected  inputs  are  in  the  block.  For  example,  if  only  the  “Delay  kit  at  a”  option  is  selected, 
items  at  the  b  and  c  inputs  are  pulled  in  until  the  quantities  required  at  each  are  filled,  then  the  a  items  are 
immediately  pulled  in.  At  least  one  of  the  "Delay  kit  at..."  choices  in  the  dialog  must  be  left  unselected.  By 
default,  the  highest  priority  that  was  on  any  of  the  input  items  is  transferred  to  the  output  item,  and  all  of 
the  input  items'  attributes  ^e  combined  in  the  output.  If  you  select  Preserve  uniqueness  in  this  block  and  in 
the  corresponding  Unbatch  block,  the  batched  item  will  unbatch  into  items  with  their  original  properties 
(attributes  and  priorities).  However,  the  Preserve  uniqueness  option  uses  more  computer  memory  and  it 
must  be  specified  in  both  blocks.  If  the  demand  connector  is  connected,  the  block  will  pull  in  items  for 
batching  only  when  demand  is  activated  (if  an  item  is  present  at  demand  or  if  the  value  at  that  connector  is 
greater  than  0.5).  If  an  item  output  connector  is  attached  to  the  demand  connector,  the  block  accumulates 
the  value  of  the  items  coming  into  it  and  passes  that  many  batched  items  out;  if  a  value  output  connector  is 
attached  to  the  demand  connector,  items  will  be  batched  as  long  as  the  value  at  demand  is  greater  than  0.5. 
This  works  similarly  to  the  demand  connector  on  the  Activity  Service  block. 


Catch 


This  block  “catches”  items  sent  by  Throw  blocks  even  though  the  blocks  aren't  connected  by 
connection  lines.  Any  number  of  Throw  blocks  can  send  items  to  a  Catch  block.  The  connection  between 
the  blocks  is  made  at  the  Throw  block  by  specifying  in  its  dialog  the  label  and  block  number  of  the  Catch 
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block.  You  could  use  the  Throw  and  Catch  blocks  instead  of  using  Combine  blocks,  even  from  inside  one 
hierarchical  block  to  inside  another  one. 


Change 

1^1 


Change  Attribute.  Changes  an  item's  attribute  value  then  passes  the  items  through.  You 
specify  the  name  of  the  attribute  to  change,  an  operation  to  use  in  the  change,  and  a  modifier  value  to 
change  with.  The  operations  are:  increment,  decrement,  multiply;  divide;  The  values  you  can  use  as 
modifiers  are:  a  constant;  the  value  from  another  attribute;  the  value  from  the  A  connector. 


Combine.  Combines  the  items  from  two  different  sources  into  a  single  stream  of  items.  This  is 
different  from  the  batch  blocks  which  join  items  from  several  sources  into  one  item.  The  items  in  the 
Combine  block  retain  their  separate  identities  and  are  not  batched  together.  Examples  of  use  are:  merging 
traffic,  customers  coming  from  two  entrances  to  form  a  single  line. 


Constant.  Generates  a  constant  value  at  each  step.  You  specify  the  constant  value  in  the  dialog  (the 
default  constant  is  1).  If  the  input  is  connected,  the  input  value  is  added  to  the  constant  in  the  dialog.  This 
block  is  typically  used  for  setting  the  value  for  the  inputs  to  other  blocks.  For  example,  you  can  use  it  for  a 
steady  flow  of  fluid,  cash,  or  a  delay  time  value.  Note:  If  the  Constant  value  field  is  left  blank  in  the 
dialog,  this  block  will  output  a  Novalue.  Outputting  a  Novalue  is  useful  in  some  situations  because  most 
blocks  will  ignore  NoValues.  For  example,  when  you  want  to  start  a  Mean  and  Variance  calculation  only 
after  a  certain  amount  of  simulation  time  has  passed;  send  NoValues  to  the  Mean  and  Variance  block  until 
you  want  calculations  to  occur.  If  you  had  input  zeros  into  the  Mean  &  Varience  block,  its  sample  size 
would  grow,  whereas  NoValues  will  be  ignored. 


Passes  items  through  and  reports  the  total  number  of  items  passed  in  its  dialog  and  at 
the  #  connector.  Item  values  are  usually  but  not  always  1 .  If  you  have  item  values  other  than  1,  and  do  not 
want  to  increment  the  count  by  item  values,  and  instead  want  the  count  to  increment  by  only  1  when  an 
item  with  a  value  greater  than  1  passes  by,  choose  Count  by  1  only.  A  value  greater  than  0.5  at  the  r 
connector  will  cause  the  count  to  be  reset  back  to  zero. 


ision.  This  block  makes  a  decision  based  on  the  inputs  and  internal  logic  you  define.  The 
dialog  lets  you  perform  the  following  tests  comparing  A  to  B:  greater  than,  greater  than  or  equal  to,  equal 
to,  less  than,  less  than  or  equal  to,  and  not  equal.  You  can  also  test  for  A  being  an  invalid  number 
(noValue).  The  block  compares  the  two  inputs  (A  and  B).  If  only  the  A  input  is  connected,  the  block 
compares  that  value  to  the  B  value  in  the  dialog.  If  the  selected  test  is  true:  the  Y  connector  outputs  1  and 
the  N  connector  outputs  0.  If  the  test  is  false:  the  Y  connector  outputs  0  and  the  N  connector  outputs  1. 
The  block  can  also  use  hysteresis.  If  this  choice  is  selected,  the  block  outputs  a  1  or  0  value  depending  on 
the  specified  test  and  the  value  for  B,  but  the  value  does  not  change  until  the  A  input  crosses  the  relaxation 
threshold.  For  example,  assume  you  select  the  Use  hysteresis  option  and  the  >  option,  and  set  B  to  9  and 
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Relax  to  7.  The  Y  connector  will  be  0  until  A  >  9,  at  which  point  it  will  become  1.  The  Y  connector  will 
stay  1  while  A>7.  As  soon  as  A  is  <=  7,  the  output  goes  to  0.  Examples  of  using  the  Decision  block  are 
contingency  planning,  pass/fail  tests,  and  routing. 

lAL 

^  ^  I  Divide.  Divides  the  top  input  by  the  bottom  input.  You  can  choose  whether  a  bottom  input  of  0 
yields  an  output  of  noValue  or  stops  the  simulation  with  an  error  message. 


Eqn 


Equation.  Outputs  the  results  of  an  equation  entered  in  the  dialog.  The  equation  must  be  of  the 
form  “Result  =  formula;”.  You  can  use  Extend's  built-in  operators  and  functions,  and  some  or  all  of  the 
input  values  as  part  of  the  equation.  Extend’s  operators  are:  +,  *,  /,  ^  (exponentiation),  MOD  or  % 

(modulus),  AND  or  &&,  OR  or  ||,  NOT  or  !,  ==  (equals),  !=  or  o  (not  equal),  <,  <=,  >,  >=  .  The 
Functions  buttons  in  the  dialog  display  a  list  of  all  built-in  functions  and  procedures,  including 
placeholders  to  remind  you  of  which  arguments  are  required.  You  can  copy  functions  from  the  listing  to 
your  equation  with  the  Copy  and  Paste  commands.  You  must  replace  the  placeholders  with  the  real 
arguments,  and  separate  arguments  with  a  comma  (,),  The  parentheses  are  required  to  show  where  the 
arguments  begin  and  end.  User-defined  functions  are  not  allowed.  Each  input  must  be  named  in  the  dialog 
in  order  to  use  it  in  the  equation.  You  can  use  the  default  input  value  names  (Varl,  Var2,  etc.)  or  specify 
new  names.  Extend  will  warn  you  if  an  input  is  used  in  the  equation  but  it  is  not  connected.  The  Equation 
block  is  discussed  fully  in  the  Extend  manual;  refer  to  the  manual  for  more  information. 


<3) 

^ount  Executive.  This  block  is  the  heart  of  each  discrete  event  model  and  must  be  placed  to  the  left  of 
all  other  blocks  in  the  model.  It  allows  the  duration  of  the  simulation  to  be  controlled  by  the  end  time  or  by 
another  number  specified  in  the  dialog.  Generally  you  will  have  no  reason  to  change  the  default  values  in 
the  dialog.  You  can  specify  in  the  dialog  that  the  simulation  end  at  the  end  time  (the  default  choice)  or  after 
a  specific  count  has  been  reached  or  a  number  of  events  have  occured.  There  are  two  ways  to  use  the  count 
or  number  of  events  choice.  If  you  enter  a  number  in  the  dialog  and  do  not  connect  to  the  count  connector, 
the  simulation  will  stop  when  the  specified  number  of  events  have  occured.  If  you  do  connect  to  the  count 
connector,  the  simulation  will  stop  whenever  the  value  at  count  has  reached  the  value  set  in  the  dialog.  The 
count  connector  compares  its  value  to  the  dialog  value  count  or  number  of  events,  if  that  choice  is  selected. 
When  the  value  at  count  equals  the  dialog  amount,  the  simulation  is  stopped.  For  example,  the  count 
connector  could  be  connected  to  the  #  connector  of  an  Exit  block  to  count  the  number  of  items  exiting  at 
that  block.  (Other  possible  connections  would  be  to  the  L  connector  on  a  Queue,  or  the  Status  connector  on 
the  Status  block).  The  “Item  rows  allocated”  field  displays  the  number  of  rows  of  data  that  the  Executive 
block  has  allocated  for  items  to  travel  through  the  simulation.  When  Extend  runs  out  of  available  item 

rows,  this  will  be  increased  by  the  number  specified  in  the  "Allocate  additional  items  in  groups  of _ " 

dialog  item.  For  an  aproximate  estimate  of  the  amount  of  memory  occupied  by  the  item  information, 
multiply  the  number  displayed  in  the  “Item  rows  allocated”  field  by  .31  for  models  without  a  Timer  block, 
and  by  .56  for  models  with  one  or  more  Timers.  This  calculation  will  give  you  the  memory  required  in  K. 
Dividing  this  number  by  1000  will  give  you  the  number  of  megabytes.  NOTE:  If  you  are  using  custom  DE 
blocks  and  you  get  an  error  message  when  running  your  model,  try  selecting  the  Use  attribute  string 
(backwards  compatible):  checkbox.  Do  not  use  this  unless  you  are  using  custom  programmed  DE  blocks 
developed  in  Extend  version  3.2  or  earlier.  If  you  are  using  custom  DE  blocks  and  you  get  an  error 
message  when  running  your  model,  try  selecting  this  checkbox. 
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Q, 


Exit.  Passes  items  out  of  the  simulation.  The  total  number  of  items  absorbed  by  this  block  is 
reported  in  its  dialog  and  at  the  #  connector. 


“Exit  (4).  Passes  items  out  of  the  simulation  from  many  inputs.  The  total  number  of  items 
absorbed  by  this  block  is  reported  in  its  dialog  and  at  the  #  connector.  The  number  absorbed  for  each  input 
is  reported  in  the  dialog  and  at  the  value  connectors  on  the  right  of  the  block. 


:  y  y  a 

N  Exponent.  Raises  the  bottom  input  (x)  to  the  power  of  the  top  input  (y).  You  can  specify  y  either 
through  the  connector  or  dialog.  The  connector  overrides  the  dialog  value. 


ile  Input.  Reads  data  from  a  text  file  and  writes  it  into  the  block's  table.  Once  the  data  is  in  the 
table,  you  can  use  it  in  your  model.  You  select  the  file  to  be  read  by  typing  its  path  name,  or  you  can  leave 
the  name  blank  so  Extend  prompt's  you  and  fills  in  the  path  name.  You  can  create  the  text  file  using 
Extend's  text  file  features,  in  a  word  processor,  or  a  spreadsheet  application.  The  file  can  have  up  to  five 
columns  of  real  data  that  are  separated  by  tabs,  spaces,  or  a  character  such  as  a  comma.  The  file  can  have  as 
many  rows  as  you  >yant,  but  you  must  specify  the  maximum  number  of  rows  that  you  want  to  read  from  the 
file  in  the  dialog.  Note  that  specifying  a  higher  number  of  rows  causes  the  block  to  allocate  more  memory. 
To  choose  which  row  from  the  table  will  be  output  into  the  model,  you  can:  *  use  the  row  connector  to 
specify  the  row  numbers,  with  0  being  the  first  row;  *  select  run  number  in  the  dialog  (each  simulation  run 
will  cause  the  next  row  of  data  to  be  output  to  the  model);  *  select  step  number  in  the  dialog  (each 
simulation  step  will  cause  the  next  row  of  data  to  be  output  to  the  model).  This  block  can  be  used  to 
control  parameters  for  many  blocks  in  a  model  or  many  runs  of  the  model. 


Output.  Writes  data  from  the  block  to  a  text  file.  You  can  type  or  paste  data  into  the  block,  or 
model  data  can  be  input  through  the  input  connectors  during  the  simulation.  You  select  the  file  either  by 
typing  its  path  name  or  you  can  leave  the  name  blank  so  Extend  prompts  you  and  fills  in  the  path  name. 

The  file  will  have  up  to  five  columns  of  real  data  that  are  separated  by  tabs,  spaces,  or  a  character  such  as  a 
comma.  You  can  write  as  many  rows  as  you  want,  but  you  must  specify  the  maximum  number  of  rows  that 
you  will  write  in  the  dialog.  Note  that  specifying  a  higher  number  of  rows  causes  the  block  to  allocate  more 
memory.  To  choose  which  row  data  will  be  input  to  during  the  simulation,  you  can:  *  use  the  row 
connector  to  specify  the  row  numbers,  with  0  being  the  first  row;  *  select  run  number  in  the  dialog  (each 
simulation  run  will  cause  data  to  be  input  into  the  next  row);  *  select  step  number  in  the  dialog  (each 
simulation  step  will  cause  data  to  be  input  into  the  next  row).  You  specify  in  the  dialog  whether  the  file  is 
written  at  the  end  of  the  simulation  or  when  you  click  the  Write  button  in  the  dialog. 


Gate  m 


0  sensor  Gate.  Allows  only  a  specified  number  of  items  to  be  in  a  section  of  the  model  (the  restricted 
section).  Use  this  block  to  restrict  the  passing  of  items  into  a  system  that  can  only  have  a  specific  number 
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of  items  in  the  system  at  a  time.  You  specifiy  in  the  dialog  the  number  of  items  which  can  be  in  the 
restricted  section  at  one  time.  The  first  items  to  arrive  are  allowed  through,  up  to  the  number  specified. 
New  items  are  only  allowed  to  pass  through  the  block  when  one  or  more  of  those  original  items  have  left 
the  restricted  section.  The  block  determines  that  an  item  has  left  the  restricted  section  when  the  sensor 
connector  views  an  input  from  the  output  of  the  last  block  in  the  section.  (The  sensor  connector  does  not 
accept  items,  but  only  notes  their  presence).  Thus  the  last  block  in  the  section  has  its  output  connected  in 
parallel:  it  is  connected  both  to  whichever  block  follows  it  and  to  the  sensor  input.  How  you  connect  this 
block  in  your  model  determines  the  restricted  section.  This  block  is  the  first  block  in  the  restricted  section. 
The  block  whose  item  output  is  connected  to  the  Gate  block's  sensor  input  is  the  last  block  in  the  restricted 
section.  To  use  this  block  in  a  model,  connect  from  the  item  output  of  the  last  block  in  the  restricted  system 
to  the  sensor  connector.  This  tells  the  Gate  block  that  an  item  has  gone  out  of  the  restricted  area,  so  it  can 
release  the  next  item.  You  must  also  connect  in  parallel  from  the  last  block's  output  to  the  next  block  in  the 
model.  For  example,  the  following  feedback  loop  can  be  used.  (This  is  similar  to  the  way  the  Timer  block 
feedback  works.)  Warning:  Only  one  viewing  type  connector  (sensor,  or  status  block  input)  can  be 
connected  to  a  given  output  connector  in  a  model.  Other  viewing  connectors  may  not  get  any  information, 
and  thus  may  not  function  properly. 


'-‘v^iU2U3  Generator.  Provides  items  for  a  discrete  event  simulation  at  specified  interarrival  times. 
Choose  either  a  distribution  on  the  left,  or  choose  the  empirical  distribution  and  enter  probabilities  in  the 
table.  Items  can  be  created  with  a  random  distribution  or  at  a  constant  rate  of  arrival.  You  can  also  specify 
the  number  of  items  output  at  each  event  in  the  dialog  or  at  the  V  connector.  This  block  provides  items  at 
specified  interarrival  rates.  Since  it  always  pushes  items,  this  block  should  usually  be  followed  by  a  Queue 
or  Resource  block  when  used  to  provide  items  for  the  model.  Otherwise,  you  may  lose  some  items  that  are 
generated.  If  an  arrival  rate  of  0  or  less  occurs,  items  are  generated  immediately  (at  the  time  the  0  or  less 
value  occurs).  The  parameters  for  the  distribution  arrival  times  are  set  in  the  dialog.  The  random 
distributions  include:  beta,  binomial,  constant,  empirical.  Erlang,  exponential,  gamma,  hyperexponential, 
log  normal,  normal,  Pearson  type  V,  Pearson  type  VI,  Poisson,  Triangular,  uniform  integer,  uniform  real, 
and  Weibull.  The  empirical  distribution  may  have  up  to  20  points  and  may  be  interpreted  as  a  discrete, 
stepped,  or  interpolated  distribution.  The  input  connectors  1, 2,  and  3  allow  you  to  change  the  parameters 
of  the  random  distribution  as  the  simulation  progresses. 


nt 


m 


ad  Get  Attribute.  Displays  and/or  removes  attributes  on  items,  then  passes  the  items  through.  The 
attribute  value  is  shown  in  the  dialog  and  output  at  the  A  connector.  You  can  also  use  this  block  to  clone 
the  item  based  on  the  number  in  an  attribute.  As  items  are  passed  through  the  block,  the  block  can  either 
read  or  remove  an  attribute,  and  that  attribute  can  be  specified  as  the  first  attribute  in  the  list  or  a  named 
attribute.  If  the  attribute  is  found,  its  value  is  reported  in  the  dialog  and  sent  through  the  A  connector.  You 
can  specify  whether  to  output  a  0  or  no  Value  at  A  if  the  attribute  is  not  found.  There  is  also  a  choice  in  the 
dialog  to  change  the  value  of  the  item  to  the  value  of  the  attribute  (clone  the  item  into  multiples).  The  D 
connector  outputs  1  if  the  attribute  value  has  changed  since  the  last  value  was  read  in. 


A^  Get  Priority.  Reads  the  priority  of  items  then  passes  them  through.  The  priority  is  shown  in  the 
dialog  and  output  at  the  P  connector.  The  priority  number  is  usually  used  to  route  items.  The  D  connector 
outputs  1  if  the  priority  value  has  changed  since  the  last  item  was  read  in. 
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Help.  Shows  help  text.  You  can  use  this  block  to  document  your  models.  Include  information 
about  what  the  model  does,  what  impact  specific  blocks  or  parameters  have  on  the  model,  authorship, 
cross-references  to  other  models,  and  so  on.  You  are  limited  to  255  characters  per  box  in  the  dialog.  If  you 
type  over  the  limit  in  a  box,  you  are  alerted  with  a  sound.  There  are  four  text  entry  boxes  in  this  block. 


istogram.  Creates  a  histogram  of  all  the  values  it  receives.  May  be  used  in  both  continuous 
and  discrete  event  models.  This  block  separates  data  into  bins  based  on  a  specified  number  of  bins  and  a 
total  range  of  values.  Each  bin  counts  the  number  of  data  values  that  fall  within  its  range.  The  number  of 
bins  and  the  minimum  and  maximum  range  values  for  the  plotter  are  specified  in  the  dialog  (the  plotter 
uses  these  numbers  to  calculate  the  range  for  each  bin).  The  maximum  and  minimum  can  be  the  entire 
range  for  the  data  received  or  specified  numbers.  Values  which  fall  outside  the  specified  range  will  not  be 
plotted  but  will  show  in  the  data  table.  You  can  specify  in  the  dialog  whether  to  plot  the  data  from  each 
step/event  or,  if  you  run  multiple  simulations,  to  plot  the  final  values  of  each  run.  The  dialog  also  displays 
the  number  of  points  received  that  fall  within  the  range.  Note:  When  using  a  specified  range,  the 
histogram  can  be  open  during  the  simulation,  wheras  using  the  max/min,  it  will  remain  closed  until  the  end, 
and  then  open  if  the  show  plot  during  simulation  checkbox  is  checked.  Note:  The  'Don't  preserve  data' 
option  will  prevent  the  plotter  from  preserving  all  the  data  points  collected  during  the  previous  run.  This 
can  be  a  large  memory  savings  if  the  plotter  is  accumulating  large  amounts  of  data,  but  it  is  incompatible 
with  the  option  of  using  the  min  and  max  values  from  the  entire  range. 


Holding  Tank.  Accumulates  the  total  of  the  input  values,  allows  you  to  request  an  amount  to 
be  removed,  and  outputs  that  requested  amount,  if  it  is  available.  The  Holding  Tank  block  is  similar  to  the 
Accumulate  block  except  that  it  allows  you  to  request  an  amount  to  be  removed  at  each  step  or  event.  The 
amount  to  be  removed  is  specified  at  the  want  connector;  the  amount  is  actually  output  at  the  get  connector, 
up  to  the  amount  available.  You  can  choose  to  allow  output  that  would  make  the  contents  go  negative 
(such  as  an  overdraft);  the  default  is  not  to  allow  withdrawals  that  make  the  contents  go  negative.  The 
Holding  Tank  block  can  serve  many  different  uses:  As  a  bank:  The  Holding  Tank  block  holds  the  money 
in  your  bank  account.  The  input  connector  receives  money.  The  C  connector  shows  the  balance  in  the  bank 
account.  The  want  connector  requests  money  be  withdrawn  from  the  bank  and  the  get  connector  is  the 
money  you  actually  withdrew  from  the  bank.  Allowing  the  contents  to  go  negative  represents  an  overdraft. 
As  a  waiting  line:  The  Holding  Tank  bank  holds  the  number  of  people  in  line.  New  people  enter  the  line  at 
the  input  connector.  The  C  connector  tells  how  many  people  are  in  line  at  a  particular  time.  The  want 
connector  tells  how  many  people  are  supposed  to  leave  the  line  at  each  step.  The  get  connector  shows  how 
many  people  actually  left  the  line.  Note  that  you  would  not  want  the  contents  to  go  negative  in  this 
situation.  As  a  reservoir:  The  Holding  Tank  block  holds  the  water  in  the  reservoir.  The  input  connector 
receives  the  amount  of  water  entering  the  reservoir.  The  C  connector  shows  the  current  level  of  the 
reservoir.  The  want  connector  specifies  the  amount  of  water  to  withdraw  from  the  reservoir  at  each  step. 
The  get  connector  gives  the  actual  amount  of  water  withdrawn.  Note  that  you  would  not  want  the  contents 
to  go  negative  in  this  situation. 


a 
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'-‘want  ‘-‘Twg  Holding  Tank  (Indexed).  This  block  represents  a  series  of  holding  tanks.  It 
accumulates  input  values,  allows  the  current  contents  to  be  reduced  by  a  certain  amount,  and  reports  the 
contents  for  the  tanks.  The  specific  tank  used  is  controlled  by  its  toggle  connector.  The  Holding  Tank 
(Indexed)  differs  from  a  Holding  Tank  in  that  it  contains  a  series  of  holding  tanks.  The  active  tank  is 
controlled  by  input  connectors  which  specify  the  index  of  the  tank  to  be  used.  Up  to  100  holding  tanks  can 
be  referenced.  Only  one  of  the  tanks  is  available  at  any  input  or  output  connector.  The  ’T"  (toggle) 
connectors  control  which  one  of  the  indexed  holding  tanks  is  being  used  for  a  connector  at  that  time  step  or 
event.  The  use  of  the.'T"  connectors  is  as  follows:  Tc  -  This  connector  controls  which  holding  tank  is 
referenced  by  the  ”C”  or  contents  connector.  Ti  -  This  connector  controls  which  holding  tank  will  get  the 
input.  Twg  -  This  connector  controls  which  holding  tank  is  referenced  by  the  "want"  and  "get" 
connectors.  You  can  think  of  each  of  these  connectors  like  a  switch.  They  allow  you  to  choose  which  of 
the  indexed  holding  tanks  will  be  used  for  the  corresponding  input/output  connector.  At  each  time  step  or 
event,  you  can  only  access  one  holding  tank  within  the  Holding  Tank  (Indexed)  block  per  input  or  output 
connector.  You  could,  however,  access  different  holding  tanks  for  the  input,  contents  or  get  connectors. 
Note  that  the  get  and  want  connectors  use  the  same  toggle  connector. 


Information.  Views  and  displays  information  about  the  items  that  pass  through  it.  The  first 
column  in  the  table  ih  the  dialog  is  the  time  the  item  arrived  in  the  block,  the  second  is  the  priority  of  the 
item,  and  the  remaining  columns  are  attribute  values  for  the  named  attributes.  You  must  specify  the  names 
of  attributes  you  wish  to  view.  If  an  attribute  is  not  found,  its  value  is  blank. 

s 

Input  Data.  Generates  a  curve  of  data  over  time  from  a  table  of  values  and  acts  as  a  lookup  table. 
This  block  is  the  same  as  the  Conversion  Table  block  except  that  the  variable  is  always  the  current  time  of 
the  simulation.  This  block  contains  a  table  of  values  (Time  and  Y  Output)  which  are  used  to  calculate  what 
the  y  output  value  would  be  for  the  current  simulation  time.  The  table  defines  a  curve;  the  output  is 
calculated  based  on  where  current  simulation  time  occurs  on  the  curve.  The  table  may  be  typed  into  the 
dialog,  imported  from  a  file,  or  pasted  from  the  Clipboard  using  the  commands  in  the  Edit  menu.  The 
values  in  the  table  do  not  need  to  be  in  sorted  order.  The  calculations  may  also  be  a  repeated  series  with 
the  time  units  between  repeats  set  in  the  dialog.  You  can  specify  that  the  simulation  should  stop  or  that  a  0 
be  output  if  the  simulation  start  time  or  end  time  is  out  of  the.  range  of  the  values  in  the  table.  It  is 
important  that  the  time  range  specified  in  the  table  at  least  covers  the  time  range  specified  in  the  Simulation 
Setup  dialog.  For  example,  if  you  enter  0  through  20  as  the  Time  values  in  the  table,  and  the  end  time  of 
the  simulation  is  40,  the  block  will  not  be  able  to  calculate  values  for  times  21-40.  In  this  case,  depending 
on  the  choices  made  for  "simulation  time  is  outside  of  table  range",  Extend  will  stop  the  simulation  and 
give  you  an  error  message  or  will  output  zeroes.  This  table  may  have  as  many  rows  of  values  as  required 
(up  to  500)  to  define  the  function,  but  it  must  have  at  least  two  rows.  The  output  may  be  interpolated  from 
the  data  or  given  a  stepped  distribution.  You  can  use  this  block  to  represent  items  which  change  over  time, 
such  as  traffic  volume,  sales  volume,  production,  and  so  on. 
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ImmaM  Input  Function.  Generates  a  function  over  time.  This  works  the  same  as  the  Conversion  Function 
block  except  that  the  variable  is  always  the  time  in  the  simulation.  A  delay  parameter  is  included  for  most 
functions  so  the  output  may  be  delayed  for  a  specified  length  of  time.  In  addition  to  the  functions  in  the 
Conversion  Function  block,  this  block  also  includes  impulse,  ramp,  and  repeated  pulse  functions,  however 
it  does  not  contain  the  modulo  and  multiplier  functions.  The  functions  that  you  can  select  from  the  dialog 
are:  absolute  value,  arccosine,  arcsine,  arctangent,  ceiling,  cosine,  cosh,  exponential,  floor,  impulse, 
lognormal,  log  base  10,  nearest  integer,  pulse,  pulse  repeated,  ramp,  sine,  sinh,  square  root,  step,  tangent, 
tanh,  and  user  defined.  You  can  also  specify  constants  to  be  used  in  an  equation  with  the  function.  The 
constants  are:  a,  b,  and  wi.  For  most  functions,  the  equation  is  output  =  a*function(b*(time~delay)).  For 
example,  if  you  choose  the  loglO  function,  the  output  will  be  a*loglO(b*(time-delay)).  The  exceptions  to 
this  rule  are:  1)  impulse:  In  this  function,  b  is  not  applicable  and  the  output  is  a/deltatime  on  the  first  time 
step  (modified  by  delay)  and  0  for  all  other  time  values.  2)  pulse:  Instead  of  b,  the  second  constant  is  wi, 
and  the  equation  is  output  =  a  for  0  □  time-delay  Dwi.  3)  pulse,  repeated:  Uses  wi  instead  of  b,  and  repeat 
instead  of  delay  as  constants.  This  function  is  the  same  as  the  pulse  function  above,  except  the  pulse  is 
repeated  every  repeat  time  units.  4)  ramp:  In  this  function,  b  is  not  applicable  and  the  equation  is  output  = 
a*(time  -  delay).  5)  step:  In  this  function,  b  is  not  applicable  and  the  equation  is:  output  =  a  if  (time-delay) 
<  0  otherwise  output  =  a  .  6)  user  defined:  Instead  of  a,  the  first  constant  is  XLo;  instead  of  b  the  second 
constant  is  XHi.  XLo  and  XHi  are  the  minimum  and  maximum  values  which  define  the  range  for  the  user 
defined  function.  You  can  define  your  own  function  by  drawing  a  curve  or  entering  values  in  a  table.  To 
do  this:  select  the  user  defined  choice  and  set  a  minimum  x  value  (XLo)  and  a  maximum  x  value  (XHi)  for 
the  time  range.  Then  click  Draw  Function.  In  the  window  that  appears,  use  the  pencil  tool  to  draw  a  curve 
which  specifies  the  relationship  of  the  output  to  time.  Alternately,  you  can  type  values  into  the  data  table  to 
specify  the  curve.  Note  that  for  most  purposes,  XLo  and  XHi  should  be  the  same  as  the  simulation  start  and 
end  times,  respectively.  If  XLo  and  XHi  are  out  of  range  (for  example  if  XHi  is  less  than  simulation  end 
time),  you  will  get  an  error  message. 


Input  Random  Number.  Generates  random  integers  or  real  numbers  based  on  the  selected 
distribution.  You  can  use  the  dialog  or  the  three  inputs,  1,  2,  and  three  to  specify  arguments  for  the 
distributions.  You  can  select  the  type  of  distribution:  Uniform  (integer  or  real).  Beta,  Binomial,  Erlang, 
Exponential,  Gamma,  Geometric,  HyperExponential,  LogLogistic,  LogNormal,  Neg.  Binomial,  Normal, 
Pearson  type  V,  Pearson  type  VI,  Poisson,  Triangular,  Weibull,  and  Empirical.  The  Empirical  distribution 
uses  a  table  of  up  to  50  values  to  generate  a  discrete,  stepped,  or  interpolated  empirical  distribution. 


^  Integrate.  Integrates  the  input  over  time.  If  present,  a  starting  value  is  added  to  the  outputs.  This 
block  may  be  used  in  a  discrete  event  model. 


H  max 
min 


Limits.  Allows  you  to  limit  the  output  value  to  a  range  of  values.  The  range  is  specified  by  the 


maximum  and  minimum  set  in  the  dialog.  The  block  passes  the  input  through  to  the  output  unless  the  input 
exceeds  the  given  maximum  limit  or  falls  below  the  given  minimum  limit,  in  which  case  the  output  is  that 
limit.  You  can  use  the  block  to  specify  volume  ranges,  salary  draw,  temperature  tolerances,  and  so  on. 
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^  ^  Logical  AND.  Performs  logical  AND  operation  on  the  inputs.  If  each  of  the  two  inputs  is  greater 
than  0.5,  the  output  is  1 ;  if  none  or  only  one  of  the  inputs  is  greater  than  0.5,  the  output  is  0. 


Logical  NOT.  Performs  logical  NOT  operation  on  the  inputs.  If  the  input  is  greater  than  0.5,  the 
output  is  0;  otherwise  the  output  is  1 . 


£>i 


y  ^  Logical  OR.  Performs  logical  OR  operation  on  the  inputs.  If  either  of  the  inputs  is  greater  than 
0.5,  the  output  is  1;  if  neither  of  the  inputs  is  greater  than  0.5,  the  output  is  0. 


i*  :£°?J-rMax  and  Min.  Determines  the  maximum  and  minimum  values  from  among  the  five  values 
input.  The  dialog  shows  the  maximum  and  minimum  values  and  the  input  connectors  they  came  from.  The 
block  outputs  the  maximum  and  minimum  values  and  their  respective  connector  numbers. 


Mean  and  Variance.  Calculates  the  mean,  variance,  and  standard  deviation  of  the  values  input 
during  the  simulation.  If  an  input  is  a  noValue,  it  is  ignored  and  does  not  affect  the  statistics.  Depending 
on  the  choice  in  the  dialog,  the  variance  is  computed  as:  Sum  of  (valid  inputs  -  mean)^2  ^  (number  of 
inputs)  or  Sum  of  (valid  inputs  -  mean)^2  (number  of  inputs  -  1)  The  variance  is  computed  using  1/(N- 
1)  as  an  averaging  factor. 

Multiply.  This  block  multiplies  the  inputs. 


Plotter,  Discrete  Event.  This  plotter  is  to  be  used  only  in  discrete  event  models.  It  is  used  to 
plot  values  such  as  information  about  items  (queue  length,  attribute  values,  number  of  items  exited,  etc). 
Both  the  value  and  the  time  the  value  was  recorded  (event  time)  are  shown  in  the  data  table  for  each  input. 
You  can  specify  in  the  dialog  whether  to  plot  values  only  when  they  change  (the  default)  or  to  plot  all 
values  (this  last  choice  plots  slower  and  uses  more  memory).  NOTE:  The  DE  plotter  defaults  to  drawing 
trace  lines  with  the  stepped  format.  We  don't  recommend  using  the  DE  plotters  with  the  trace  lines  drawn 
as  interpolated  lines.  There  are  several  problems  with  doing  this.  For  one,  the  combination  of  the  plot 
important  data  option  in  the  dialog  box  and  the  interpolated  mode  can  cause  the  interpolation  to  be  done 
wrong.  The  reason  for  this  is  that  the  plot  important  data  option  causes  points  that  have  the  same  value  as 
the  previous  point  to  be  ignored,  and  therefore  the  interpolation  will  be  drawn  from  the  first  of  the  points 
with  a  given  y  value,  rather  then  the  last.  The  other  potential  problem  with  interpolation  has  to  do  with  the 
nature  of  discrete  event  simulation.  Discrete  event  simulations  will  output  points  at  arbitrary  time  intervals, 
and  an  interpolated  line  drawn  between  two  of  these  points  is  not  necessarily  an  accurate  reflection  of  the 
actual  data. 
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.  Prioritizes  the  outputs,  allowing  items  to  be  sent  into  parallel  process  activities  based 
on  a  user-defined  priority.  Items  arrive  through  the  item  input  connector.  They  are  made  available  at  one  of 
the  five  item  output  connectors  based  on  two  things:  the  specified  priorities,  and  whether  or  not  the  items 
are  needed  at  the  output.  In  order  of  its  priority,  each  output  will  be  checked  to  see  if  an  item  is  needed. 

The  item  will  leave  through  the  highest  available  prioritized  output.  If  two  or  more  outputs  have  the  same 
highest  priority,  the  output  closest  to  the  top  will  be  checked  first  to  see  if  the  item  is  needed;  if  it  isn't 
needed  there,  the  next  lower  output  with  that  same  priority  will  be  checked.  Note  that  this  block  differs 
from  the  Set  Priority  block  which  assigns  priorities  to  the  items.  In  the  Prioritizer  block,  the  priorities  are 
assigned  to  the  outputs;  no  priority  attaches  to  the  items.  This  block  also  differs  from  the  Select  DE  Output 
block  in  that  the  item  will  go  through  the  block  to  the  highest  available  prioritized  output,  whereas  in  the 
Select  block,  the  item  will  only  go  through  if  the  specific  path  chosen  can  take  an  item.  The  Priorities  are 
specified  in  the  dialog,  or  can  be  modified  through  the  five  value  input  connectors,  overriding  the  dialog 
values.  The  value  input  on  the  left  corresponds  to  the  priority  for  the  top  output  connector;  the  value  input 
on  the  right  corresponds  to  the  priority  for  the  bottom  output  connector.  Priorities  are  specified  as  real 
numbers,  with  the  lowest  number  (including  negative  numbers)  representing  the  highest  priority.  For 
example,  assume  the  first  three  outputs  (a,  b,  and  c)  are  connected  and  are  assigned  the  priorities  2,  1,  and 
3,  respectively.  When  an  item  arrives,  the  block  will  check  output  b  first,  to  see  if  it  needs  an  item.  If  b 
needs  the  item,  the  item  is  output  there.  If  not,  output  a  will  be  checked,  then  output  c. 


©start  Program.  Provides  items  by  scheduling  many  items  to  be  output  into  the  model.  This  is 
similar  to  the  Generator  block,  except  the  arrival  times  of  the  items  are  scheduled  rather  than  random.  Also, 
you  can  assign  a  value,  a  priority,  and  attributes  to  each  item  generated.  These  items  (with  a  given  output 
time,  item  value,  priority,  attribute  name,  and  attribute  value)  may  repeat  on  a  regular  basis.  This  block  is 
useful  for  repetitive  or  timed  needs.  Up  to  500  events  can  be  generated  before  repeating  a  sequence.  The 
block  provides  items  only  at  the  specified  times.  Since  this  block  always  pushes  items,  when  you  use  it  to 
provide  items  in  a  simulation,  it  should  usually  be  followed  by  a  queue  or  resource  block.  Otherwise,  you 
may  lose  items.  If  you  use  this  block  to  activate  a  universal  connector,  you  do  not  need  to  connect  to  a 
queue  or  resource  first:  you  would  connect  directly  to  the  universal  input.  If  the  start  connector  is  not 
connected,  the  timing  of  the  program  entered  in  the  dialog  is  in  absolute  simulation  time.  For  example,  an 
Output  Time  of  2  in  the  Program  dialog  will  occur  at  simulation  time  2,  as  long  as  simulation  time  2 
actually  occurs  (it  would  not  occur  if  the  simulation  starting  time  is  later  than  2).  If  the  start  connector  is 
used,  the  Output  Time  entered  in  the  dialog  is  relative  to  when  the  start  connector  is  activated.  For 
example,  if  Output  Time  is  2  and  start  is  activated  at  simulation  time  1,  the  program  will  start  at  time  3 
(1+2).  The  start  connector  is  activated  whenever  it  receives  an  item  or  a  true  value  (a  value  >  0.5).  If  there 
are  no  additional  arrivals  specified,  the  start  connector  will  restart  the  program.  The  first  row  of  the 
Program  block  must  be  filled  in.  Attributes  are  only  output  if  an  attribute  name  is  given.  The  program  ends 
at  the  first  blank  row. 


^  Prompt.  Prompts  for  a  value  to  output  if  the  inputs  meet  a  test.  Until  the  test  is  met,  the  block 
outputs  a  value  specified  in  the  dialog.  When  the  test  is  met,  the  block  prompts  for  a  new  output  value,  then 
outputs  that  value.You  select  one  of  two  tests,  both  comparing  input  a  to  the  value  b  (b  is  specified  in  the 
dialog,  or  by  the  b  connector,  which  overrides).  The  first  test  is  if  a  is  greater  than  b,  the  second  is  if  a  is 
less  than  or  equal  to  b.  You  can  specify  that  you  should  be  prompted  only  the  first  time  the  test  is  met  (in 
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which  case  that  prompt  value  will  be  output  for  the  remainder  of  the  simulation),  or  to  wait  a  period  of  time 
before  testing  the  condition  again.  You  may  enter  your  own  prompt  message  in  the  dialog  by  typing  over 
the  default  prompt  message.  If  you  click  the  cancel  button  in  the  prompt,  the  simulation  is  stopped.  Note 
that  the  output  of  this  block  can  be  any  value,  whereas  the  Decision  block  outputs  only  1  or  0.  You  would 
use  this  block  to  pause  a  simulation,  request  a  value  from  the  user,  then  continue  the  simulation  using  the 
new  value. 


iFvF  Queue,  Attributes.  A  queue  where  items  with  a  particular  attribute  have  a  higher  priority  than 
other  items.  If  there  are  no  attributes  to  prioritize,  this  becomes  a  simple  FIFO  queue.  Any  items  that  do  not 
have  the  attribute  at  all,  will  fall  to  the  back  of  the  queue.  Up  to  four  different  attribute  names  may  be  listed 
in  the  dialog.  If  the  A  connector  is  not  connected,  the  attribute  named  at  the  top  of  the  list  has  the  highest 
priority  and  the  other  attributes  listed  are  ignored.  If  connected,  the  value  at  the  A  connector  selects  which 
of  the  four  named  attribute  has  the  priority.  The  top  attribute  is  selected  by  an  X  value  of  1,  the  bottom 
attribute  by  an  X  value  of  4.  By  default,  only  the  presence  or  absence  of  the  attribute  is  considered.  If  the 
“Sort  by  attribute  value”  option  is  chosen,  the  items  will  be  further  sorted  by  the  value  of  the  attributes.  The 
default  sort  order  is  Highest  value  first,  meaning  from  highest  value  (including  negative  numbers)  to 
lowest. 


Ii^ip 

L&^po  Queue,  FIFO.  A  first-in-first-out  (FIFO)  queue.  The  maximum  length,  which  determines  how 
many  items  the  queue  can  hold,  can  be  set  in  the  dialog.  You  can  specify  that  the  simulation  should  stop 
when  the  queue  is  full  (reaches  the  maximum  length).  You  can  also  see  the  average  queue  length,  average 
wait  time,  and  utilization  of  the  queue  in  the  dialog. 


W= 

Queue,  LIFO.  A  last-in-first-out  (LIFO)  queue.  The  maximum  length,  which  determines  how 
many  items  the  queue  can  hold,  can  be  set  in  the  dialog.  You  can  specify  that  the  simulation  should  stop 
when  the  queue  reaches  the  maximum  length  (is  full).  You  can  also  see  the  average  queue  length,  average 
wait  time,  and  utilization  of  the  queue  in  the  dialog. 


iCT. 


Queue,  Matching.  A  queue  in  which  items  are  released  only  if  they  have  the  specified  attribute 
and  the  attribute's  value  matches  die  value  at  the  ID  connector.  The  block  searches  an  item  entering  the 
queue  to  find  the  attribute  named  in  the  dialog.  If  the  attribute’s  value  matches  the  value  at  the  ID 
connector,  the  item  is  released.  If  there  is  more  than  one  item  with  that  attribute  name  and  value,  only  the 
first  one  that  entered  the  block  is  released  unless  the  "Release  multiple  items"  option  in  the  dialog  is 
selected.  You  can  vary  the  value  at  the  ID  connector  so  that  all  items  with  the  named  attribute  are  released. 
Note  that  items  which  don't  have  the  named  attribute  will  never  be  released  from  the  queue.  This  block  is 
useful  for  being  sure  that  items  in  a  simulation  have  a  particular  characteristic  at  a  particular  time. 
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Queue,  Priority.  A  queue  that  releases  items  by  priority.  The  item  in  the  queue  with  the  lowest 
numerical  value  for  its  priority  will  be  released  first.  If  the  items  in  the  queue  all  have  the  same  priority,  it 
becomes  a  first-in-first-out  (FIFO)  queue.  The  maximum  length,  which  determines  how  many  items  the 
queue  can  hold,  can  be  set  in  the  dialog.  You  can  specify  that  the  simulation  should  stop  when  the  queue  is 
full  (reaches  the  maximum  length). 


im 


Queue,  Resource  Pool.  A  queue  for  resource  pool  units.  Items  wait  until  the  specified  number  of 
resource  pool  units  become  available.  The  order  of  items  in  the  queue  is  determined  by  the  ranking  rule  in 
the  dialog  of  the  Resource  Pool  block.  The  maximum  length,  which  determines  how  many  items  the  queue 
can  hold,  can  be  set  in  the  dialog.  You  can  also  see  the  average  queue  length,  average  wait  time,  and 
utilization  of  the  queue  in  the  dialog. 


leadOut.  Displays  the  value  at  the  input  connector  at  each  simulation  step.  This  block  comes 
to  the  front  of  the  screen  during  a  simulation  run  if  the  “Open  dialog”  option  is  selected,  even  in  front  of 
any  plotters  you  may  have  open.  This  is  useful  for  debugging  models  and  scripts  because  you  can  see  the 
value  of  another  block’s  value  output  connector  at  any  time.  The  NTicks  field  in  the  dialog  allows  you  to 
set  a  delay  in  ticks  (®ths  of  a  second)  for  the  block  to  pause  while  displaying  each  number. 


IPooIO  I 

•^change  Release  Resource  Pool.  Releases  a  resource  pool  as  the  item  passes  through.  This  pool  of 
resource  units  can  be  released  by  either:  1)  -  Choosing  the  ’’Release  Resource  Pool  by  name”  radio  button 
and  entering  the  name  of  the  Resource  Pool  block  and  the  number  of  units  to  be  released.  2)  -  Choosing 
the  ’’Release  resource  pool  by  attribute”  radio  button  and  specifying  an  attribute  which  has  been  set  by  a 
Queue,  Resource  Pool  block.  The  Resource  Pool  is  immediately  released  and  will  check  its  list  of  items 
requesting  the  resource  pool  to  see  if  it  can  be  allocated  to  a  different  item.  Note:  The  order  in  which  the 
item  goes  to  the  release  blocks  specifies  the  order  in  which  the  Resource  Pool  blocks  are  activated  to  check 
for  waiting  items.  In  situations  where  the  resource  allocation  is  complex  (multiple  resource  pools  are  being 
allocated  at  once  and  different  items  will  require  different  resource  pools),  it  is  generally  recommended  to 
release  the  Resource  Pool  which  is  expected  to  have  the  highest  utilization  first.  This  will  give  this  resource 
an  opportunity  to  allocate  itself  before  other  resource  pools.  * 
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y change  Resource.  This  block  holds  and  provides  items  (cars,  workers,  orders,  etc)  to  be  used  in  a 
simulation.  It  can  be  used  as  part  of  an  open  or  closed  system.  Unlike  the  Generator  and  Program  blocks, 
this  block  does  not  push  items.  If  you  use  it  in  place  of  a  Generator  or  Program  block  to  provide  items  for 
the  simulation,  be  sure  that  there  are  sufficient  items  in  initial  number  to  satisfy  item  requirements  for  the 
duration  of  the  simulation.  This  block  is  similar  to  a  queue.  Items  can  be  pulled  from  the  resource  through 
the  item  output  connector  as  long  as  they  are  available.  If  the  block’s  contents  become  negative,  the  block 
will  not  output  any  values  until  the  contents  become  a  positive  number.  The  change  connector  modifies 
the  number  of  items  stored  in  the  resource  by  the  value  of  the  item  at  change.  (The  main  difference 
between  the  regular  item  input  and  the  change  input  is  that  the  input  at  change  may  be  negative,  reducing 
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the  number  of  items  available  in  the  block.)  You  can  add  attributes  and  priorities  to  items  passing  through 
the  block  or  strip  attributes  from  them.  If  you  use  this  block  as  part  of  a  closed  system  and  you  strip 
attributes,  the  default  attributes  will  become  the  items'  attributes.  If  you  do  not  strip  attributes  (such  as  in  an 
open  system),  the  default  attributes  are  added  to  the  items'  attributes. 


rpg.. 


^  Release 
N 


m 


Resource  Pool.  This  block  holds  resource  pool  units  to  be  used  in  a  simulation.  These  units 
limit  the  capacity  of  a  section  of  a  model.  For  example,  this  could  be  used  to  represent  a  limited  number  of 
tables  at  a  restaurant.  Unlike  the  Resource  block,  the  resource  pool  units  are  not  items.  They  are  variables 
which  indicate  how  much  of  a  constraining  factor  is  available.  The  Resource  Pool  block  works  with  the 
Queue,  Resource  Pool  to  allocate  the  pool  of  resources  to  items  and  it  works  with  the  Release  Resource 
Pool  block  to  release  the  pool  of  resources.  Items  can  wait  for  a  resource  pool  from  any  number  of  Queue, 
Resource  Pool  blocks.  The  Resource  Pool  block  determines  the  order  in  which  the  resource  pool  units  are 
allocated.  Units  can  be  allocated  to  either  the  item  which  arrived  first  in  the  Queue,  Resource  Pool  block  or 
the  item  with  the  highest  priority  (the  lowest  numerical  priority  value).  If  the  Only  allocate  to  the  highest 
ranked  item  option  is  checked,  only  one  item  will  be  considered  when  the  resource  pool  allocation  is 
attempted.  If  this  is  not  checked,  the  pool  will  look  through  all  of  the  items  waiting  until  it  finds  both  the 
first  item  which  can  leave  the  Queue,  Resource  Pool  block  and  a  sufficient  number  of  available  resource 
pool  units.  The  change  connector  modifies  the  number  of  resource  pool  units  available  by  the  value  of  the 
item  at  change.  (The  main  difference  between  the  regular  item  input  and  the  change  input  is  that  the  input 
at  change  may  be  negative,  reducing  the  number  of  units  available  in  the  block.) 


^  Retain.  Outputs  the  initial  value  set  in  its  dialog  until  the  T  connector  is  TRUE  (greater  than  0.5), 
then  outputs  the  value  of  its  input  while  T  is  TRUE.  This  block  retains  the  current  value  at  its  input  when  T 
becomes  FALSE.  While  T  is  FALSE,  the  retained  value  is  output.  If  T  becomes  TRUE  again,  the  block 
outputs  and  retains  the  current  value  at  its  input.  The  initial  value  must  be  specified  in  the  dialog  (the 
default  initial  value  is  0).  The  value  retained  and  output  is  changed  to  the  value  of  the  input  only  when  the 
value  at  the  T  connector  is  TRUE  (greater  than  0.5). 


select  ®  Select  DE  Input.  Selects  one  input  to  be  output  based  on  a  decision.  The  item  that  is  present  at 
the  selected  input  is  passed  through  the  output.  The  dialog  has  options  for  choosing  based  on  the  top 
■priority,  changing  which  input  is  selected  after  a  given  number  of  items  have  passed,  or  choosing  based  on 
the  select  connector.  For  example,  you  can  use  this  block  to  represent  traffic  signals  at  an  intersection, 
candidate  selection,  CPU  interrupt  access,  and  so  on.  If  the  select  connector  is  not  used,  you  can  have  one 
out  of  a  specified  number  of  items  come  from  the  bottom  connector,  or  you  can  choose  based  on  priority.  If 
you  choose  based  on  priority,  the  input  with  the  highest  priority  is  selected  for  output.  If  both  inputs  have 
the  saihe  priority,  the  top  input  is  output.  The  first  input  will  be  taken  from  the  top  connector  when  one  of 
every  N  items  are  coming  from  the  bottom.  If  the  select  connector  is  used,  the  dialog  has  options  for 
toggling  (choosing  the  inputs  sequentially  each  time  select  is  activated)  or  choosing  the  input  based  on  the 
value  at  the  select  connector.  •  If  you  choose  to  toggle  the  inputs  based  on  the  select  connector  value,  the 
block  will  choose  the  input  sequentially  each  time  select  is  activated  (each  time  select  pulls  in  an  item  or 
sees  a  value  >  0.5).  If  select  is  not  activated  (for  instance,  if  it  sees  a  value  of  0)  and  there  is  an  item 
available  for  output,  the  item  will  come  from  the  last  input  that  was  selected.  If  an  item  is  connected  to  the 
select  connector,  the  output  will  be  changed  each  time  an  item  arrives  to  the  select  connector.  •  If  you 
choose  to  have  the  input  selected  based  on  the  value  at  the  select  connector,  each  valid  value  at  select  will 
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choose  an  input  based  on  the  input  connector’s  assigned  number.  The  number  corresponding  to  the  top 
input  connector  is  set  in  the  dialog;  the  bottom  input  is  1  more  than  the  number  for  the  top  input.  Invalid 
values  at  select  are  values  which  do  not  correspond  to  the  numbers  assigned  to  the  inputs.  You  can  choose 
whether  invalid  values  at  select  cause  Extend  to  choose  the  top  input  connector  or  to  not  pull  in  an  item 
until  the  select  connector  has  a  valid  input.  If  an  item  is  connected  to  the  select  connector,  the  value  of  the 
item  is  used  to  determine  which  output  will  be  used.  If  the  select  connector  is  connected  to  one  or  more 
Get  blocks  (such  as  Get  Attribute,  Get  Priority),  then  you  should  be  careful  to  avoid  putting  the  following 
types  of  blocks  in  between  the  select  and  the  Get  blocks:  Set  blocks  (Set  Attribute,  Set  Priority,)  activities, 
and  queues.  These  blocks  can  alter  the  value  that  you  use  for  the  select  input. 


rp 

a  ?  b 

©select  Select  DE  Output.  Selects  the  input  item  to  be  output  at  one  of  two  output  connectors  based  on  a 
decision.  The  item  at  the  input  is  passed  through  the  selected  output.  The  dialog  has  options  for  changing 
the  outputs  after  a  given  number  of  items  have  passed  and  selecting  based  on  the  select  connector.  If  the 
select  connector  is  not  used,  you  can  have  1  out  of  every  specified  number  of  items  go  to  the  bottom 
connector.  If  the  select  connector  is  used,  the  dialog  has  options  for  toggling  (choosing  the  outputs 
sequentially  each  time  select  is  activated)  or  choosing  the  output  based  on  the  value  at  the  select  connector. 
The  first  input  will  be  sent  to  the  top  connector  when  one  of  every  N  items  are  going  to  the  bottom.  1)  •  If 
you  choose  to  toggle  the  outputs  based  on  the  select  connector  value,  the  block  will  choose  the  top  and  the 
bottom  outputs  sequentially  each  time  select  is  activated  (each  time  select  sees  a  value  >  0.5).  If  select  is 
not  activated  and  there  is  an  item  available  for  output,  the  item  will  go  to  the  last  output  that  was  selected. 
If  an  item  output  connector  is  attached  to  the  select  connector  and  you  choose  toggle,  the  select  block  will 
switch  outputs  each  time  an  item  arrives  to  the  select  connector.  2)*  If  you  choose  to  have  the  output 
selected  based  on  the  value  at  the  select  connector,  each  valid  value  at  select  will  choose  an  output  based 
on  the  output  connector’s  assigned  number.  The  number  corresponding  to  the  top  output  connector  is  set  in 
the  dialog,  the  number  of  the  bottom  output  is  1  more  than  the  top  output.  Invalid  values  at  select  are 
values  which  do  not  correspond  to  the  numbers  assigned  to  the  outputs.  You  can  choose  whether  invalid 
values  at  select  cause  Extend  to  output  the  item  at  the  top  output  connector,  at  the  bottom  output 
connector,  or  to  not  pull  in  an  item  until  the  select  connector  has  a  valid  input.  If  an  item  output  connector 
is  attached  to  the  select  connector,  the  select  block  will  choose  the  connector  corresponding  to  the  value  of 
the  item  arriving  to  the  connector.  If  the  select  connector  is  connected  to  one  dr  more  Get  blocks  (such  as 
Get  Attribute,  Get  Priority),  then  you  should  be  careful  to  avoid  putting  the  following  types  of  blocks  in 
between  the  select  and  the  Get  blocks:  Set  blocks  (Set  Attribute,  Set  Priority,)  activities,  and  queues.  These 
blocks  can  alter  the  value  that  you  use  for  the  select  input. 


Select  Input.  Selects  its  output  to  be  either  of  two  input  values  based  on  a  threshold  test.  The  block  acts 
like  a  switch.  The  value  to  be  output  is  determined  by  comparing  the  value  of  the  T  connector  to  a  critical 
value  set  in  the  dialog.  When  the  value  of  the  T  connector  is  less  than  the  critical  value,  the  top  input  is 
used;  when  the  value  of  the  T  connector  is  greater  than  or  equal  to  the  critical  value,  the  bottom  input  is 
used.  This  block  is  useful  for  any  sorting  procedure.  The  default  for  the  critical  value,  0.5,  works  well  for 
boolean  logic  since  Extend  booleans  have  true  equal  to  1  and  false  equal  to  0. 


Select  Input  (5).  Selects  its  output  to  be  one  of  five  inputs  according  to  the  value  of  the  T 
connector.  The  top  input  is  selected  if  the  T  connector  is  1,  and  the  bottom  input  is  selected  if  the  T 
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connector  is  5.  The  dialog  also  lets  you  specify  an  output  value  of  either  noValue  or  0  if  the  value  at  T  is 
out  of  the  range  of  1  to  5  . 


T  Select  Output.  Passes  the  input  value  to  one  of  two  output  connectors  based  on  a  threshold  test. 
The  output  connector  is  selected  by  comparing  the  value  of  the  T  connector  to  a  critical  value  specified  in 
the  dialog.  When  the  value  of  the  T  connector  is  less  than  the  critical  value,  the  top  output  connector  is 
used;  when  the  value  of  the  T  connector  is  greater  than  or  equal  to  the  critical  value,  the  bottom  output 
connector  is  used.  For  the  unselected  output  connector,  the  dialog  lets  you  specify  an  output  value  of  either 
noValue,  0,  or  a  repeat  of  the  last  value  it  output.  The  default  for  the  critical  value,  0.5,  works  well  for 
boolean  logic  since  Extend  booleans  have  true  equal  to  1  and  false  equal  to  0. 


“'T  Select  Output  (5).  Passes  the  input  value  to  one  of  five  outputs  according  to  the  value  of  the  T 
connector.  The  top  output  is  selected  if  the  T  connector  is  1  and  the  bottom  output  is  selected  if  it  is  5.  For 
connectors  that  are  not  selected,  the  dialog  lets  you  specify  an  output  value  of  either  noValue,  0,  or  a  repeat 
of  the  last  value  they  output. 


m 


Set  A 

IQII 


A  Set  Attribute.  Sets  the  attributes  of  items  passing  through  the  block.  Up  to  seven  attribute 
names  and  values  may  be  assigned  to  an  item  with  each  Set  Attribute  block.  The  attributes  may  add  to  or 
replace  existing  item  attributes.  You  can  specify  the  value  of  one  of  the  attributes  with  the  A  connector. 
The  value  at  the  A  connector  overrides  the  corresponding  value  in  the  dialog.  If  the  attribute  name  is 
already  present  on  the  item  passing  through,  the  old  value  will  be  stripped  off,  and  the  new  value  will  be 
substituted  for  it. 


J  SetA(5) 

^  1011 


m 


"ETuuu  u'  Set  Attribute  (5),  Sets  the  attributes  of  items  passing  through  the  block.  Up  to  five  attribute 
names  and  values  may  be  assigned  to  an  item  with  this  block.  The  attributes  may  add  to  or  replace  existing 
item  attributes.  You  can  specify  the  value  of  each  of  the  attributes  with  the  value  input  connectors;  these 
connectors  override  values  set  in  the  dialog.  This  works  similarly  to  the  Set  Attribute  block  except  that  you 
c^  use  the  value  input  connectors  to  set  the  value  for  each  of  the  five  attributes  rather  than  for  just  one.  If  * 
the  attribute  name  is  already  present  on  the  item  passing  through,  the  old  value  will  be  stripped  off,  and  the 
new  value  will  be  substituted  for  it. 


Set 

illl 


m 


P  Set  Priority.  Assigns  a  priority  to  items  that  pass  through.  The  priority  value  may  be  set  at  the 
P  connector  or,  if  no  connection  is  made  there,  in  the  dialog.  Note  that  the  lowest  value  (including  negative 
numbers)  has  the  top  priority. 
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Set  V 


Set  Value.  Assigns  a  value  to  items.  This  is  used  to  change  an  item’s  initial  value  of  1  to  a 
different  value.  Items  originally  have  a  value  of  1  unless  the  value  is  changed  by  the  Set  Value,  Generator, 
Get  Attribute,  Program,  or  Schedule  blocks.  You  would  use  this  to  have  one  item  represent  a  group  of 
items  as  it  travels  through  the  simulation,  or  to  have  an  item  with  a  value  greater  than  1  to  cause  a  demand 
at  the  Activity  Service  block.  Note:  queues  split  items  with  a  value  greater  than  one  into  clones.  For 
example,  if  you  set  a  value  of  5  on  an  item,  when  it  goes  into  a  queue,  it  will  become  five  distinct  items. 


Times.  Displays  when  the  next  event  will  occur  for  each  block  in  the  model.  The  block 
displays  the  requested  next  event  times  and  their  index  numbers.  To  see  events  as  they  are  posted,  leave 
this  block’s  dialog  open  when  running  a  simulation.  You  can  specify  in  the  dialog  how  long  the  block 
should  pause  before  updating  the  display.  The  index  number  of  event-posting  blocks  is  based  on  the 
simulation  order.  For  example,  index  number  0  will  be  the  first  event-posting  block  in  the  model.  You  can 
calculate  the  index  value  of  a  block  by  counting  the  number  of  event  posting  blocks  in  the  simulation  order 
before  the  block  you  are  interested  in.  The  Executive  block  initializes  the  time  array  to  blanks.  This  means 
those  blocks  not  requesting  events  will  not  show  any  values  in  the  data  table  in  the  Show  Times  dialog.  If 
your  model  has  more  than  2000  blocks  posting  events,  the  table  will  show  only  the  first  2000.  The  Show 
Times  block  will  not  blank  out  old  events,  but  will  save  them  in  the  table  until  updated  by  a  block.  This 
block  must  be  placed  to  the  right  of  all  blocks  to  display  events  from  all  blocks. 


^^Hill^Status.  Views  and  displays  information  about  an  item  or  values.  For  items:  Connect  the  Status 
block’s  item  input  to  any  block’s  item  output  connection  to  view  the  items  moving  through  the  connection. 
The  Status  block's  dialog  lists  a  great  deal  of  information  about  the  items  at  that  connector,  including:  • 
number  present  at  the  beginning  of  the  simulation  step  (available  at  onset)  •  number  currently  at  the  output 
connector  (available  currently)  •  total  number  of  items  that  came  into  the  block  (total  input)  •  interval 
between  arrival  times  of  items  (interval)  •priority  ‘attributes  By  default,  the  block  views  items  (does  not 
remove  them  from  the  model).  The  block  can  also  be  set  to  absorb  items  and  thus  be  used  like  the  Exit 
block  (use  this  choice  with  caution). 

Subtract.  Subtracts  the  bottom  input  from  the  top  input. 


System  Variable.  Allows  you  to  regulate  some  aspect  of  the  model  based  on  the  status  of  the 
simulation.  It  is  usually  used  in  conjunction  with  a  decision-type  block,  for  example,  to  halt  a  process  after 
current  time  reaches  a  certain  value.  The  variables  you  can  use  are:  current  run  number,  current  step, 
current  time,  end  time,  number  of  runs,  number  of  steps,  start  time,  and  time  step. 


P\  ^Throw  jjirow.  This  block  "throws"  items  to  a  Catch  block  without  using  an  output  connector  or 
connection  lines.  Any  number  of  Throw  blocks  can  send  items  to  a  single  Catch  block.  The  connection 
between  the  blocks  is  made  by  specifying  the  label  and  block  number  of  the  Catch  block  in  the  Throw 
block’s  dialog.  You  could  use  the  Throw  and  Catch  blocks  instead  of  using  Combine  blocks,  even  from 
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inside  one  hierarchical  block  to  inside  another  one.  Choose  either  a  specific  Catch  block  to  throw  to  or  a 
Catch  block  based  on  an  attribute  value. 


.  Displays  the  time  that  it  takes  an  item  to  pass  between  two  parts  of  the  model.  The 
block  adds  a  time  tag  to  an  item  passing  through  and  records  it  in  a  list  in  the  dialog.  You  can  find  how 
long  it  takes  for  the  item  to  get  from  this  block  to  another  one  (the  target  block)  by  attaching  the  sensor 
connector  to  the  output  of  the  target  block.  You  can  also  specify  to  time  only  items  with  a  particular 
attribute.  The  data  table  displays  the  time  each  item  leaves  this  block.  It  also  displays  the  delay  time  (the 
time  it  takes  for  the  item  to  travel  to  the  target  block  once  it  leaves  the  Timer).  If  you  want  the  delay  time 
to  also  include  the  time  items  wait  to  be  pulled  into  the  next  block,  you  should  follow  the  Timer  block  with 
a  FIFO  queue  so  that  the  item  waits  in  the  queue  (and  that  wait  time  will  be  counted).  Since  the  data  table  is 
limited  to  the  Maximum  number  of  items  timed  at  once,  items  beyond  that  number  write  over  the  first  item. 
Thus  items  cycle  through  the  data  table.  If  the  maximum  number  of  items  is  unknown  or  if  the  items  need 
to  be  timed  over  multiple  paths,  attributes  can  be  used  to  record  the  timing  information.  Assign  an  attribute 
to  the  current  time  (the  System  Variable  block  in  the  Generic  library  will  return  the  current  simulation 
time)  when  the  item  arrives.  At  the  point  where  the  item  is  finished  processing,  get  the  value  of  the 
attribute  (Get  Attribute  block)  and  subtract  this  from  the  current  time.  How  you  connect  this  block  in  the 
model  determines  the  section  in  which  the  item  will  be  timed.  The  Timer  is  the  first  block  in  the  timing 
section;  the  target  block  is  the  last  block  in  the  timing  section.  The  output  of  the  target  block  should 
connected  in  parallel  with  the  Timer  and  the  block  after  the  target.  Thus  the  last  block  in  the  section  has  its 
output  connected  in  parallel,  that  is,  connected  to  both  the  block  that  follows  it  and  to  the  sensor  input. 
Warning:  Only  one  viewing  type  connector  (sensor  or  status  block  input)  can  be  connected  to  a  given 
output  connector  in  a  model.  Subsequent  connectors  may  not  get  any  information  and  so  may  not  function 
properly. 


.  Produces  several  items  from  a  single  input  item.  The  number  of  items  produced  at 
each  output  are  specified  in  the  dialog.  By  default,  this  block  holds  its  inputs  until  its  outputs  are  used  or 
another  demand  occurs  at  the  connector.  The  attributes  and  priorities  of  the  input  item  are  copied  to  each 
output.  If  you  selected  preserve  uniqueness  in  the  Batch  block  and  here,  items  will  be  output  with  their 
original  properties  (attributes  and  priorities)  restored.  This  block  can  be  used  to  break  a  message  packet 
into  component  messages,  route  the  same  message  to  several  places,  or  distribute  copies  of  invoices.  Items 
are  pulled  in  continuously  or  upon  demand  if  the  demand  connector  is  used.  If  the  demand  connector  is 
connected,  items  are  only  pulled  in  if  demand  is  activated  (if  an  item  is  present  at  demand  or  if  the  value  at 
that  connector  is  greater  than  0.5).  •  If  an  item  input  connector  is  attached  to  the  demand  connector,  the 
block  accumulates  the  value  of  the  items  coming  into  demand  and  pulls  in  that  many  items.  •  If  a  value 
output  connector  is  attached  to  the  demand  connector,  items  will  pass  through  as  long  as  the  value  at 
demand  is  greater  than  0.5.  This  works  similarly  to  the  demand  connector  on  the  Activity  Service,  block. 
Since  the  Unbatch  block  has  no  storage  capability,  all  of  the  outputs  must  be  pulled  from  the  block  before 
another  item  may  be  pulled  in.  Note  that  each  non-zero  value  for  Output  at...  in  the  dialog  must  have  its 
corresponding  output  connected. 


©demand 
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APPENDIX  G.  MODEL  BANDWIDTH  AND  FUTURE  REQUIREMENTS 

[Boyd,  Mayo,  IT21,  FRD,  ERDB] 

Model  Bandwidth  (See  Appendix  I  for  Unit  and  System  Bandwidth) 


User  Group 

Back  Channel 

IP  (Variable)  Data  Rqmts 

CVBG 

SHF 

1.792  Mbps 

CVBG 

Challenge  Athena 

768  kbps 

CVBG 

Inmarsat  B 

640  kbps 

CVBG 

Iridium 

24  kbps 

CVBG 

HF 

578.4  kbps 

CVBG 

UHFDAMA 

31.2  kbps 

CVBG 

EHF 

24  kbps 

CVBG  in  Extend  Model  =  1  CVN  +  2  CG  +  2  DDG  +  2  DD  +  2  FFG  +  3  SSN  +  1  AGE 

Extend  Model  CVBG  SHF  =  768k  +  2(256k)  +  2  (256k)  +  0  +  3(0)  +  3(128K)  +  0  =  1.792  Mbps 

Extend  Model  CVBG  Comm.  WB  (Challenge  Athena)  =  768k  +  2(0)  +  3(0)  +  3(0)  +  0  =  768  kbps 

Extend  Model  CVBG  Comm.  WB  (Inmarsat)  =  64k  +  2(64k)  +  2(64k)  +  2(64k)  +  2(64k)  +  3(0)  +  64k  =  640  kbps 

Extend  Model  CVBG  Comm.  NB  (Iridium)  =  2.4k  +  2(2.4k)  +  2(2.4k)  +  2(2.4k)  +  2(2.4k)  +  3(0)  +  2.4k  =  24  kbps 

Extend  Model  CVBG  HF  =  2.4k  +  2(64k)  +  2(64k)  +  2(64k)  +  2(64k)  +  3(0)  +  64k  =  578.4  kbps 

Extend  Model  CVBG  HHF  DAMA  =  2.4k  +  2(2.4k)  +  2(2.4k)  +  2(2.4k)  +  2(2.4k)  +  3(2.4k)  +  2.4k  =  31.2  kbps 

Extend  Model  CVBG  LT)R  EHF  =  2.4k  +  2(2.4k)  +  2(2.4k)  +  2(2.4k)  +  2(2.4k)  +  3(0)  +  2.4k  =  24  kbps 

Extend  Model  Total  Allocation  for  CVBG  =  3.8576  Mbps 


Chronology  of  Bandwidth  Requirements 
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Current  Bandwidth  Requirements  (FY  98/99  IT-21  Implementation 


Precision 

Engagement 

1280  Kbps 


LHA / LHD  LSD / LPD 
OMFTS 


768Kbps  Primary  Imagery 


S12  Kbps _ 

384  Kbps  Collaborative  Planning 


SIPRNet-64Kbps 

NIPRNet-64Kbps 


Voice  >128  Kbps 
VTC  -  128Kbps 


Tele>medicine  -  Radiography/Diagnostics 


AADC 
12  units 


CG/DDG  DD/SSN  FFG 
TMD 


IT  21  CORE 
CAPABILITY 
128Kbps 


64  Kbps  Common  Tactical  Picture  (GEO  satcoiw) 

JTIDS,  Link  16 


64  Kbps  Tactical  Data  Network  (GEO  satcom) 

COMMON  OPERATIONAL  PICTURE  NSFS,  IBS 

RECORD  MSG  /  EMAIL  TELEMEDICINE  (E-mail  /  Image  Capture) 


2.4  Kbps  CMD  VOICE  NET  (SKhz  uhf/ehf  ldr) 


CBS: 

INMARSAT  B: 
ATM  lAH: 
SHF: 


1  SHF;  . 

512  -  768  Kbps  /  1.5  Mbps  max  j 

CAHI: 
GBS:  : 
ATM  LAN; 

CVBG 


GBS: 

INMARSAT  B: 
ATM  LAN: 


156 


Current  Bandwidth  Requirements  (continued) 


Future  Bandwidth  (FYDP,  2003) 


CVBG  in  2003  =  1  CVN  +  2  CG  +  3  DDG/DD  +  3  FFG  +  3  SSN  +  1  AOE 


Future  Bandwidth  (2010  for  JTF,  SW  Asia  MTW,  CVN,  CG,  LHD/LHA)  [ERDB] 


CVBG  in  2010  =  1  CVN  +  2  CG  +  3  DDG  +  3  SSN  +  1  AOE 


Naval  Battle  Force  Requirements  (Kbps) 


Wide 

Band 

Narrow 

Band 

Prot 

Total 

Groups 

Deployed 

Total 

Ships 

Sub 

Total 

218,856 

222.418 

5 

50 

1.112,090 

ARG 

111,456 

737 

5 

25 

576.S45 

Fleet 

69.560 

3.218 

Mmm 

77,566  1 

1 

24 

77,566 

(•)  Actual  amount  of  forcaa  daployad  In  scmtiino  dapanotanf  Total  [  99  |  1,766,201  [ 
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2010  Unit  Bandwidth  Requirements  (CVN,  LHD/LHA,  CG) 


Platform 


79.1Mbps 


Platfom 


71.S  Mbps 


Platform 


rzja  Mbps 


SATCOM 

Systems 


iCommM  WB 


I 


MiLSTAR 

(ADVEHF) 


UFO/E 


SATCOM 

Systems 


loses  (AWB)1 


Comm’IWB 


I  CommMNB  . 


MILSTAR 

(ADVEHF) 


UFOAE 

SATCOM 

Systems 

loses  (AWB)^ 
I  Conim‘l  WB 


I  urofANor 
I  CommT  NB 


MILSTAR 
{ADV  EHF) 


UFO/E 


Requirement 
Category 
(Approx  Ki^s) 


Systems 


Wdeband 
(77,808  Kbps) 


Narrowband 
(198  Kbps) 


SIPRNET 

MPRMET 

JWICS 

T»t*m»d/yrC 

DSN 


lm«Q«y(SIDS> 
ComiTiMMWTC 
CEC 


Ottttftor* 

fKbcm} 

1.544 

2,045 

1.024 

2.04S 

t.544 

1344 

512 

10.000 

50.000 


MW  (Vote*) 
casL 

Lintc-11 

IT-21 

jnos 


Protected  J 
(1,114  Kbps)  I 

*  Mn  mnmttiAn  9  IIAV 


SATHCOM 

SOF 

Dl»( 

BrosOOiSt 


Z4 

1,024 


No  more  than  2  UAV  sensor  links  active  per  CVBG 


) 


Requirement 
Category 
(Approx  Ki^) 


Wideband 

(70,264) 


Narrowband 
(172  Kbps) 


l^tected 

(1,090  Kbps) 


Systems 


Ciraiit 


1,544 
1344 

JWICS  Z04a 

T*lemwWTC  1,024 
OSH  2,M5 

trtMQ«ry(SI)S)  1344 
ComnwKWTC  S12 
CEC  10,000 

njAV  Sensor  50,000 


Strike 

AAW  (Voice) 
csa. 

Unk-ll 

IT-21 

JT10G 


1 


SATHICOM 

OtSN 

8raadee« 


Z4 

1.024 

64 


*  No  more  than  1  UAV  sansor  link  active  per 


Requiiement 
Category 
(Approx  K^) 


Wideband 
(71,904  Kbps) 


Systems 


1 
I 

}' 

Protected  J 
(601  Kbps)  1 

*  No  more  than  2  UAV  aem 


DttMfUi* 

Circulf  fKbtxi 

StPBNer  512 

NIPRNET  512 

JWeS  1344 

Tel«me<WTC  512 
DSN  768 

tmeeefy  (S»S)  1344 

CommeMWTC  512 
CEC  10,000 

*  UAV  Seneer  50.000 


6,000 


Narrowband 
(324  Kbps) 


AAW  (Voice} 

C5EL 

Unki-ll 

CUDetaUnk 

JT-21 

JUDS 


SATHICOM 

OtSN 


'  No  more  than  2  UAV  sensor  links  active 
t  No  more  than  10  CM  sensor  links  active 


23 

512 


per  CVBG 
per  CVBG 
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APPENDIX  H.  SATCOM  PRIORITY  TABLE  [CJCSI] 

PRIORITY  USER  CATEGORY 

PRIORITY  0  ASSIGNED  ONLY  BY  NCA/ JOINT  STAFF  FOR  EMERGENT 

CRITICAL  CONTINGENCY  SUPPORT 

PRIORITY  I.  STRATEGIC  ORDER  (ESSENTIAL  TO  NATIONAL 

SURVIVAL) 

lA  System  Control/Orderwire 
IB  National  Command  Authorities 
IBl  Presidential  Support 
1B2  Secretary  Of  Defense  Support 
1B3  Envoy/ Emissary  Support 
iC  Strategic  Warning/ Intelligence 

ICl  CINCSTRAT  Force  Direction 
1C2  PAC/LANT/EUR  Force  Direction 
1C3  USCINCSTRAT  Airborne  Resources 
ID  Slop  REQUIREMENTS 

IDl  USCINCSTRAT  Force  Element 

REPORT  BACK 

1D2  PAC  /  LANT/  EUR  Report  Back 
1D3  Comm  Between  SIOP  and  CINCs 

PRIORITY  n.  WARFIGHTING  REQUIREMENTS 

2A  Department  Of  State  Diplomatic  Negotiations 
2B  CJCS  Support 

2C  CINC  (CINCs  Will  Rank  Requirements  Within  (Each  Priority 
Categoty) 

2DJTF/CTF 

2E  Component  Support  (Theater  Forces) 

2F  Tactical  Warning/ Intelligence 
2G  CJCS-Sponsored  Select  Exercises 
2H  Counter-Narcotics  Operations 
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PRIORITY  m.  ESSENTIAL  SUPPORT 


3A  Other  Intelligence  (e.g.,  Technical,  Economic) 

3B  Weather 
3C  Logistics 
3D  MIJI  Support 
3E  Diplomatic  Post  Support 

3F  Space  Vehicle  Support  (Minimum  Circuits  For  TT&C  From 
Space  Vehicles  and  Primary  Circuits  for  Manned  Space 
Flights) 

3G  Other  Service  Support 
PRIORITY  IV.  TRAINING 
4 A  CJCS  Sponsored 

4B  CINC  Sponsored  (CINCs  Prioritize  Tmg  Reqmts.) 

4C  MAJCOM/MACOM/ Echelon  2  Sponsored 
4D  Unit  Sponsored 

PRIORITY  V.  VIP  SUPPORT 

5 A  Service  Secretaries 

5B  Service  Chiefs  (CNO/CMC/CSA/CSAF) 

5C  CINC  Travel 
5D  Other  Travel 

PRIORITY  VI.  RDTSsE  and  GENERAL 

6A  DoD  Sponsored  Testing 
6B  DoD  Sponsored  Demonstrations 
'6C  Administrative  Support 
6D  Quality  Of  Live  Initiatives 

PRIORITY  Vn.  MISCELLANEOUS 

7 A  DoD  Support  To  Law  Enforcement 
7B  Other  Non-DoD  Support 
7C  Non-Us  Support  As  Approved  By  CINCs 
7D  Other 
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APPENDIX  I.  EXTEND  DEFAULT  NOTEBOOK  SETTINGS 


Message  Rate  (messages  per  hour) 


KAWia  wimm  ■iiiMa  iriuaa  imm  iriifetai  ■agaai  ijiifeM  Eiaia  emb  KaaiM  KjiatHa 


1  IsTmT-M 

5000 

ISH 

600 

600 

600 

600 

360 

360 

1320 

240 

240 

240 

1  Msgs  1 

1000 

rno 

1  132  1 

no 

no 

no 

no 

66 

66 

242 

44 

44 

44 

■asai 

10000 

BItMiM 

BleHiM 

1100 

noo 

1100 

1100 

660 

660 

2420 

440 

440 

440 

1  FTP  1 

1000 

132 

naa 

no 

no 

no 

no 

66 

66 

242 

44 

44 

44 

BSSSi 

500 

72 

72 

60 

60 

60 

60 

36 

36 

132 

24 

24 

24 

1  Tact.  1 

500 

72 

72 

60 

60 

60 

60 

36 

36 

132 

24 

24 

24 

Message  Size  (bits) 


—  WMiism  WM.^m  ggasM  iritTchU  iriiigEa  ElgaB  IMfcM  liiaieM  E^M  Ktlsmi  IskiadM  EBSga  IjfeafcfeM 
■aMB  W1  IWihM  iKiiflM  lEEM  IBBM  aMiaiiil  IMiiihii  IBESM  1BEE1 

■AI.-y.-M  laailiiaM  gMM  ■aimini  ■rfilililiM  gaiiiiw  ■■•tilililiM  ■amiw  Ji  ^ailiaM  B.-lililiM  BTiTiBliM  ■giTiTiTM  ■aitiHW 


280k 

BlitflaB 

280k 

280k 

280k 

1  280k  1 

ESilSai 

280k 

280k 

280k 

280k 

280k 

1  FTP  1 

120k 

BMiliW 

■w 

120k 

120k 

120k 

120k 

120k 

120k 

120k 

120k 

120k 

KSBM 

8000 

■AW 

■ABIiM 

8000 

8000 

8000 

8000 

8000 

8000 

8000 

8000 

8000 

8000 

8000 

■:W 

lAIsW 

8000 

8000 

8000 

8000 

8000 

8000 

8000 

8000 

8000 

8000 

Standard  Deviation  of  Message  Size  (bits) 


1 

1  CVN72 

KcHcl 

■rfcfAB  liTgasg 

HHEgSgl 

iigi^ 

iwmm 

1  FFG48 

1  FFG51 

immm 

1  SSN713 

1  SSN716 

1  SSN759 

1  2500 

IBSSIiB 

1  2500 

1  2500 

1  2500 

1  2500 

1  2500 

■  BgilBB 

1  2500 

1  2500 

1  2500 

lAiMa  BltliEM  BE5EG1  tufliMJ  PaamM  mjifliM  icaljigM  iiaiMai  BUMM  BEW  jjMiii  Bli|t|tl»M  Bltfi1«T«1  BE551 

ESuaa 

1  60000 

1 

1  wmmm 

lEHa 

1  KiTiTiM 

1  EiIiIiIiB 

1  gaiWIBB 

■  litiMtM 

■  EiIiIiIiM 

1  60000 

1  60000 

1  60000  1 

■3if  ■  lihhliM  BitrthM  temiBiM  Klil'ili'lM  ■mimif  BiiliUliM  ■wiiuii J  ■MiaMtlB  hMiiiiiliM  BTilililM  BtiliM  Btililill 

1  1500 

IBCBiai 

1  1500 

1  1500 

1  1500 

1  1500 

1  1500 

1  1500 

1  1500 

1  1500 

1  1500 

1  Tact. 

1  1500 

1  irohl 

■HAM  ■l.tiHl 

1  1500 

1  1500 

hsoo_ 

1  1500 

1  1500 

1  1500 

1  1500 

1  1500 

1  1500 

Bandwidth  Capabilities  (bps) 


SHF 

CA 

Inmarsat  B 

HF 

Iridium 

UHF 

EHF 

GBS  Chi 

RB  System 

1.9M 

2.4M 

64k 

Variable 

2400 

2400 

2400 

N/A 

CVN72 

768k 

768k 

64k 

2400 

2400 

2400 

2400 

15M 

CG63 

256k 

N/A 

64k 

64k 

2400 

2400 

2400 

15M 

CG67 

256k 

N/A 

64k 

64k 

2400 

2400 

2400 

15M 

DDG65 

256k 

N/A 

64k 

64k 

2400 

2400 

2400 

15M 

DDG69 

256k 

N/A 

64k 

64k 

2400 

2400 

2400 

15M 

DD966 

N/A 

N/A 

64k 

64k 

2400 

2400 

2400 

15M 

DD973 

N/A 

N/A 

64k 

64k 

2400 

2400 

2400 

15M 

FFG48 

N/A 

N/A 

64k 

64k 

2400 

2400 

N/A 

15M 

FFG51 

N/A 

N/A  • 

64k 

64k 

2400 

2400 

N/A 

15M 

AOEIO 

N/A 

N/A 

64k 

64k 

2400 

2400 

N/A 

15M 

SSN713 

64k 

N/A 

N/A 

OFF 

OFF 

2400 

2400 

15M 

SSN716 

64k 

N/A 

N/A 

OFF 

OFF 

2400 

2400 

15M 

SSN759 

64k 

N/A 

N/A 

OFF 

OFF 

2400 

2400 

I5M 

RB  system _ Protocols _ User  Requests 


MTU 

Alt.  rkm) 

Overhead 

MTU 

Prod  Reas 

Tact.  Reas 

SHF 

2368 

35786 

IP 

160 

12000 

50%  Imag. 

60%  Tact. 

CA 

2368 

35786 

TCP 

160 

See  RB  svst 

25%  Word 

30%  Image 

Inmarsat 

2368 

35786 

FDDI 

6 

N/A 

25%  Video 

5%  Word 

HF 

4608 

N/A 

ATM 

40 

424 

5%  Video 

Iridium 

4608 

787 

UDP 

64 

See  RB  svst 

UHF 

840 

35786 

EHF 

4608 

35786 
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APPENDIX  J.  GBS  PRODUCTS  [Arthur] 


Information  Product 


MAPPING,  CHARTING  AND 
GEODESY  ((GGIS)) 


2  METEOROLOGICAL  AND 

OCEANOGRAPHIC  (METOC) 


ARMY  NOTICES  OF 
AMMUNITION 
RECLASSIFICATION  (NARS) 


MISSILE  NOTICE  OF 
AMMUNITION 
RECLASSIFICATION  (NARS) 


5  OVERHEAD  FIRE 

SUPPLEMENTAL  NOTICES 


6  TPFDL 


7  I  COMMON  TACTICAL  PICTURE 


8 


9  lATO 


10  SOFTWARE 

UPDATES/PATCHES 


1 1  MEDICAL  INTELLIGENCE 


12  GTN  (ITV,  JTAV/JTAD) 


13  SARSS-O/RF/ 


Class  Pt.  Of  Origin 


S  NPMOC 


U  HQ,  JOC 


SBM  End  User  HW/SW  Rqmts 


Source 


SIPRNET  Browser  Applications 


SIPRNET  Browser,  MPEG  viewer 


AUTODIN  AMHS 


U  I  HQ,  MICOM  I  AUTODIN  AMHS 


HQ,  JOC 


CINCPAC  J3/4/5 


AUTODIN  AMHS 


GCCS  (5CCSRDA 


J3  (GCCS/JMCIS)  GCCS  GCCS  3.0 


CMSA  (CRUISE  CP  SMITH  7AF=MDS  ,  Ships=Fire 

MISSILE  SUPPORT,  B/20  Control  Sys 

PACOM  &  ACOM) 


OSAN  CTAPS 


JICPACetal 


7  AF 


MULTIPLE 

SOURCES 


AFMIC,  WHO,  JTF  ArMedSurvA  WALTER  REED 
cty 


BROWSER 


USTRANSCOM 


14 

INTEGRATED  BROADCAST 
SERVICE  (IBS) 

X 

s 

NSAmRO/AIA 

(JICPAC) 

UHFvia 

landline 

CTT/MATT->JTT 

15 

USE/LOCATION  OF  WMD 

X 

s 

JTF,  JICPAC 

SIPRNET 

Browser  Applications 

16 

INTEL  IMAGERY 

X 

s 

JICPAC 

SIPRNET 

HTML,  5D,  IPL  client 

m 

DAILY  INTELLIGENCE 
BULLETIN  (DIB) 

X 

TSC 

JICPAC 

TSC  Feed 

HTML,  FrameReader, 

Adobe  Acrobat 

18 

DAILY  INTEL  SUMMARY 
(DISUM) 

X 

s 

JICPAC 

SIPRNET 

Browser  Applications 

19 

COUNTRY  FACT  SHEETS 

X 

s 

JICPAC 

SIPRNET 

HTML,  FrameReader, 

Adobe  Acrobat 

20 

DEFENSE  INTELLIGENCE 
WARNING  SYSTEM 

X 

s 

JICPAC 

SIPRNET 

Browser  Applications 

X 

s 

JICPAC 

SIPRNET 

Browser  Applications 

22 

POL-MIL  AND  TACTICAL 
ADVISORIES 

X 

s 

JICPAC 

SIPRNET 

Browser  Applications 

■ 

TACMILINTSUM  AND  SI- 
TACMILINTSUM 

X 

TSC 

JICPAC 

TSC  Feed 

Browser  Applications 

24 

EXPEDITIONARY  SUPPORT 
PACKAGE 

X 

S 

JICPAC 

SIPRNET 

Browser  Applications 

25 

FEASIBILITY  ASSESSMENT 
SUPPORT 

X 

s 

i  JICPAC 

j 

SIPRNET 

Browser  Applications 

26 

MILITARY  CAPABILITIES 
STUDY  (MCS) 

•  X 

s 

JICPAC 

SIPRNET 

HTML,  FrameReader, 

Adobe  Acrobat 

27 

JICPAC  SPECIAL  REPORT 

X 

s 

JICPAC 

SIPRNET 

Same  as  Above 

28 

TARGET  SYSTEM  ANALYSIS 

X 

s 

JICPAC 

SIPRNET 

Same  as  Above 

29 

LINES  OF  COMMUNICATIONS 
ROUTE  STUDY 

X 

s 

JICPAC 

SIPRNET 

Browser  Applications 
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OPERATIONAL  TARGET 
GRAPHIC  (OTG) 

X 

BASIC  TARGET  GRAPHIC  (BTG) 

X 

QUICK  RESPONSE  GRAPHICS 
(QRG) 

X 

i^iisinnrMai^n 


IMAGERY  INTERPRETATION 
REPORT 


3  5  MODERNIZED  INTEGRATED 
DATABASE  (MIDB) 


36  CONTINGENCY  EXPED./SOF 
PRODUCT  (CESP) 


37  *NEO  DATABASE  *Not  listed  in 
message 


38  CURRENT  INTELLIGENCE 
BRIEF 


39  J2  CHALLENGES  BRIEF 


40  CNN 


41  AFRTS 


42  UAV/HUD  VIDEO  DOWNLINK 


43  COMMAND  INFORMATION 


44  BDA 


45  PSYCHOLOGICAL 

OPERATIONS  PRODUCTS 


46  PREVENTIVE  MEDICINE 

ORIENTATION  AND  TRAINING 


I 


MEDICAL  SIGNIFICANT 
TRAINING 


48  *NEO  SUPPORT  *Not  listed  in 
message 


49  EMERGENCY  ACTION 
MESSAGES  (EAM) 


50  CINC  FORCE  DIRECTION 
MESSAGES  (FDM) 


5 1  SITUATION  REPORTS 
■  (SITREPS) 


52  FRIENDLY  ORDER  OF  BATTLE 
(FOB)  DATA 


53  ENEMY  ORDER  OF  BATTLE 
(EOB)  DATA 


INTEGRATED  TARGETING 
ORDER  (ITO) 

X 

TARGET  NOMINATION  DATA 

X 

JICPAC 

SIPRNET 

JICPAC 

SIPRNET 

JICPAC 

SIPRNET 

JICPAC 

SIPRNET 

JICPAC 

SIPRNET 

JICPAC 

SIPRNET 

JICPAC 

SIPRNET 

JICPAC 

SIPRNET 

JICPAC 

JWICS 

JICPAC 

JWICS 

CABLE  TV 
(BRDCST  STATION) 

OCEANIC 

CABLE 

MARCH  AFB,  CA 
(BRDCST  STATION) 

INTELSAT  ' 
177W 

Browser  Applications 


Browser  Applications 


Browser  Applications 


Browser  Applications 


Browser  Applications 


Browser  Applications 


Browser  Applications 


Browser  Applications 


Monitor 


Monitor 


Television 


Television 


TSC  I JTF 


S 


SVCS, 

COMPONENTS 
(NAVY  EPMU’S) 


SRVCS  (ECHELON 
III  UNITS, 
MEDICAL 
TEACHING  FACIL.) 


NAVY 

EPMU’S 


HTML,  Monitor 


Television 


Monitor 


Monitor+H63 


S 

COMUSKOREA 

SIPRNET 

s 

USFK 

(CINCUNC/CFC  & 
USFK) 

SIPRNET 

s 

USFK 

(CINCUNC/CFC  & 
USFK) 

SIPRNET 

s 

USFK  (CFC  FIELD 
UNITS  & 

SUPPRTNG  ORGS/ 
ELEMENTS) 

SIPRNET 

s 

SAME  AS  ABOVE 

SIPRNET 

s 

USFK 

COMPONENTS 

(COMPONENT 

COMMANDS) 

SIPRNET 

s 

USFK  (CINCCFC, 
JICPAC,  TARGET 
NOMINATION 
BOARDS, 

SIPRNET 
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56 

COLLECTION  MANAGEMENT 
(RFIS) 

57 

HUMINT 

58 

GRAPHIC  INTSUMS  (Intel 
Summaries) 

59 

INTELLIGENCE  ESTIMATE 
PRODUCTS 

60 

KOREA  TACTICS,  TECHNIQUES 
AND  PROCEDURES  (KTTP) 

61 

SIMULATIONS 

62 

THEATER  MISSILE  DEFENSE 
INTEL  PREPARATION  OF  THE 
BATTLEHELD  (TNiO  IPB) 

63 

SIGNALS  INTELLIGENCE 
(SIGINT)  f 

64 

JSTARS 

65 

VIDEO  TELECONFERENCE 
(VTC)  BROADCASTS 

'  66 

DISTANCE  LEARNING 

67 

NONCOMBATANT 
EVACUATION  OPERATION 
(NEO)  SUPPORT 

COMPONENT 

COMMANDS) 


USFK  (CP  TANGO, 
OSAN  AND  CAMP 
HUMPHREYS, 
JICPAC) 


USFK  (YONGSAN, 
CP  TANGO,  OSAN, 
HUMPHREYS) 


USFK  (YONGSAN 
IN  ARMISTICE,  CP 
TANGO,  CAMP 
HUMPHREYS, 
OSAN) 


USFK  C2  (CFC  C2) 


USFK  C2  (CFC  C2) 


USFK,  USCP 
(YONGSAN,  OSAN, 
TAEGU,  CP  TANGO, 
SUWON,  PACOM) 


USFK  (YONGSAN, 
OSAN,  CP  TANGO, 
HUMPHREYS) 


USFK  (YONGSAN, 
OSAN,  CP  TANGO, 
K-50,  HUMPHREYS) 


JSTARS  MGSM 
(WARTIME  MGSM 
LOCATIONS) 


USFK 

(CINCCFC/USFK 
AND  VARIOUS 
PENINSULA 
COMMAND 
CENTERS) 


USFK  (ALLU.S. 
MILITARY  POSTS 
AND  CAMPS  IN 
ARMISTICE. 
YONGSAN,  OSAN, 
HUMPHREYS, 
TAEGU,J12 
CHINHAE, 
POHANG,  AS  A 
MIN.) 


USCP,  NEP  CTRS 
(PACOM,  NEO 
CENTERS) 
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APPENDIX  K.  GBS  MODEL  DATA  TABLES 


The  following  pages  of  data  tables  were  tabulated  from  Extend-collected  data 
during  one  65-second  simulation.  The  Extend  data  was  incorporated  into  Excel™ 
spreadsheets  to  make  it  easier  to  read  and  better  organized.  Page  170  provides  the 
request-to-information  time  stamps  for  product  requests  (tactical  data,  imagery, 
documents,  and  video).  Page  171  shows  the  attributes  associated  with  the  items  on  page 
170.  Pages  172-175  provide  the  complete  time  stamps  for  the  entire  request-to-receipt 
cycle.  These  pages  are  organized  by  ships  (the  CVN  is  first).  Lastly,  pages  176-179 
provide  the  attributes  that  are  associated  with  the  same  numbered  items  in  the  time  stamp 
sections. 
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Word/PowerPoint  Results  (Time  Stamps  in  seconds)-  Simulation  One 


0.00187577 


0.00187577  0.035788452  0.109381965  0.122495104 


0.00187577 


I  mUTiS  Wii  Ml  lc»  [g  W?i  ■  t:i  E  I 

IM<l»Mkl4MIKKgl.MHEqiai<a^ 


IKIES&ES3I 


Video/Audio  Results  (Time  Stamps  in  seconds)-  Simulation  One 


3.11808772 


0.000195141  0.015654445  7.65411911  8.030970777 


lOtTiItll 

|ia»ItWct:?:WgiWE[:iW>g:^gl[ 


32.50418234 


32.74292084 
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CVN  72  Results  (Time  Stamps  in  seconds)-  Simulation  One 


LANOutTime  |  ADNS-Time  |  Entry-Time  |  Info-Time  |  NCTAMS-Time 


TimeforRequest  TimetoDeliver 


0.268154884 


3.767321013 1  0.266480339  1  3.500840674 


0.025747128  0.513224116 


EVMWmiri 


8.477610864 


0.754858914  I  12.08703016 


0.000577516 


I  [  |  |  |  |  |  |  H  |  |  |  jj 


0.973001767 


1.026046534 


1.2117402621  1.213414899 


16.53464857  16.89794174 


9.021989581 


12.84188907 


13.08054398 


16.89794174 


1.020690164 


1.211740262  I  17.59610944 


1.258748491 


1.450478756  18.07358642 


1.690891887 


1.735071596 


19.638249  20.00154217 


0.000942316 


0.001721434 


r.r.!.m=!:r.H; 


lEEBS 


1.973810091 


2.178894937 


2.219219867 


2.401872237 1  2.412277061 1  2.41429779 


2.163133743 


rtBfagiaiMi 
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DDG65  Results  (Time  Stamps  in  seconds)-  Simulation  One 
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AOE10  Results  (Time  Stamps  In  seconds)-  Simulation  One 


NO  AVAILABLE  DATA  DUE  TO  EITHER  UNKNOWN  MODEL  ERROR  OR  SHORT  SIMULATION  DURATION 
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CVN  72  Results  (Attributes)  -  Simulation  One 
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DD967  Results  (Attributes)  >  Simulation  One 


UnitBandwidth 


HBammcgagcBaaiaaHi 


PropagDistance 

#Collisions 

(km) 

(ReqsOut) 

NO  AVAILABLE  DATA  DUE  TO  EITHER  UNKNOWN  MODEL  ERROR  OR  SHORT  SIMULATION  DURATION 


SSN713  Results  (Attributes)  -  Simulation  One 


FFG48  Results  (Attributes)  -  Simulation  One 


NO  AVAILABLE  DATA  DUE  TO  EITHER  UNKNOWN  MODEL  ERROR  OR  SHORT  SIMULATION  DURATION 


AOE10  Results  (Attributes)  -  Simulation  One 


NO  AVAILABLE  DATA  DUE  TO  EITHER  UNKNOWN  MODEL  ERROR  OR  SHORT  SIMULATION  DURATION 
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APPENDIX  L.  GLOSSARY  [GBS,  IBS] 


1 .  Airborne  Receive  Terminal  (ART)  -  A  GBS  receive  terminal  installed  on  airborne 
platforms,  to  include  fixed  and  rotary  wing  aircraft.  This  receiver  will  receive  while  on  the  move. 

2.  Broadcast  Stream  -  The  aggregation  of  video  and  data  products  into  a  continuous  digital  stream  to  be 
transmitted  to  the  space  segment.  Broadcast  streams  are  created  by  the  Satellite  Broadcast  Manager, 
processed  and  transmitted  to  the  space  segment  by  the  injection  terminal,  and  received  and  processed 
by  the  receive  suite  (receive  terminal,  cryptographic  equipment  and  Receive  Broadcast  Manager)  for 
subsequent  dissemination  to  end  user  systems. 

3.  Broadcast  Management  «•  The  set  of  functions,  processes,  and  systems  required  to  collect,  assemble, 
prioritize,  transmit,  encrypt  or  decrypt,  and  disseminate  information  provided  from  information 
producers  to  end  user  systems.  Divided  into  two  parts:  transmit  broadcast  management  and  receive 
broadcast  management. 

4.  Broadcast  satellites  -  Satellites  with  high-power  transponders  capable  of  broadcasting  data  at  rates  up 
to  24  megabits  per  second. 

5.  Broadcast  services  -  Delivery  of  information  products  by  the  GBS  system  which  users  employ  to 
improve  their  combat  effectiveness. 

6.  Defense  Information  Infrastructure  (DII)  -  Resources  identified  by  the  Defense  Information 
Systems  Agency  (DISA)  as  critical  for  the  flow  of  information  within  the  Department  of  Defense. 
Interoperability  and  multi-path  technologies  are  being  applied  to  the  DII  to  make  it  as  flexible  as 
possible.  DISA  and  NSA  are  also  working  on  a  multi-level  security  capability  for  the  DII. 

7.  Defense  Information  Systems  Network  (DISN)  -  A  network  of  communications  paths  that  support 
information  transfer  within  the  DOD. 

8.  Direct  satellite  broadcasting  -  A  commercially  developed  system  of  satellites,  equipped  with  high- 
power  transponders,  and  small  receivers  and  antennas,  which  deliver  broadcast  television  and  data 
services  to  commercial  users. 

9.  End  User  -  The  ultimate  recipient  and/or  user  of  the  information  products  broadcast  by  the  GBS. 

10.  End  User  System  -  An  end  user  owned  and  operated  system  that  uses  information  provided  via  the 
GBS. 

1 1 .  File  -  A  discrete  or  fixed  size  information  product.  Imagery,  weather  information,  maps,  and  Air 
Tasking  Orders  (ATO)  are  examples  of  file  products. 

12.  Fixed  -  Not  intended  to  be  moved. 

13.  Fixed  Ground  Receive  Terminal  (FGRT)  -  A  GBS  receive  terminal  installed  in  a  fixed  location. 

This  receiver  will  not  receive  while  on  the  move. 

14.  Fully  Connected  (FC)  Mode  -  In  this  mode,  the  receive  suite  can  receive  the  GBS  broadcast  and  a 
"return”  channel  exists  over  which  rebroadcast  requests  are  transmitted  on  a  packet-per-packet  basis 
using  split  protocols.  The  requests  are  automatically  generated  by  the  RBM  and  a  virtual  full-duplex 
connectivity  is  achieved.  However,  user  pull  is  not  automatically  generated.  The  users  must  still 
request  their  products  from  the  source  by  whatever  means  are  available  to  them.  The  likelihood  that 
the  users  are  connected  to  some  existing  network  is  high  and  they  will  make  their  user  pull  requests  via 
the  various  applications  programs  they  have  access  to  (e.g.,  SIPRNET  and  INTELINK). 

15.  Global  Broadcast  Service  (GBS)  -  An  Acquisition  Category  (ACAT)  ID  DOD  program  providing  a 
system  of  satellites  and  commercially  developed  receivers  used  by  a  CINC-responsive  or  -directed 
broadcast  management  structure  to  support  the  flow  of  national  and  theater  level  generated 
information  products  to  forces  deployed,  on  the  move  (in  transit),  or  in  garrison, 

16.  GBS  Receive  Terminal  -  A  small  satellite  antenna  and  receive  equipment  that  will  receive  and 
convert  the  downlink  GBS  radio  frequency  (RF)  signal  into  a  broadcast  stream. 

17.  GBS  Resource  Allocation  Tool  (GRAT)  -  A  software  tool  providing  a  means  of  operational  control 
over  what,  when,  and  to  whom  information  is  disseminated  in  a  particular  AOR  via  GBS 
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18.  Global  Coverage  -  For  GBS,  90  o  North  to  65  o  South  latitude,  180  o  West  to  180  o  East  longitude. 

19.  Ground  Mobile  Receive  Terminal  (GMRT)  -  A  GBS  receive  terminal  which  is  capable  of  receiving 
and  processing  the  GBS  downlink  while  on  the  move. 

20.  Hyperlinks  -  A  method  for  information  producers  to  connect  one  information  file  to  another.  This  is 
common  technique  used  when  exploring  the  Internet. 

21.  Information  Dissemination  Management  (IDM)  -  The  function  of  providing  the  right  information  to 
the  right  place  at  the  right  time  in  accordance  with  commanders’  policies  and  optimizing  the  use  of 
information  infrastructure  resources.  IDM  is  “  content  aware”  in  that  it  provides  access  to  information, 
may  integrate  information  from  multiple  sources,  archives  products,  and  may  format  some  information 
for  transmission  on  the  selected  media.  It  involves  the  safeguarding,  compilation,  cataloging,  caching, 
distribution,  and  retrieval  of  data;  manages  the  flow  of  information  to  users;  and  enables  the  execution 
of  commanders’  information  policy 

22.  Information  Management  -  Information  management  enables  warfighting  decision  makers  to 
collaborate  with  information  producers  to  get  relevant  information,  generate  knowledge  and 
understanding  about  the  Battlespace,  and  empower  successful  decision  making. 

23.  Information  Producer  -  A  provider  of  file  or  stream  information  products.  Information  producers  are 
categorized  as  national  and  theater. 

24.  Information  Products  -  File  and  stream  products  from  national  and  theater  information  producers  to 
be  delivered  to  end  users  by  the  GBS  system. 

25.  Injection  Points  -  Hardware  and  software  that  implements  the  functions  necessary  to  transmit 
broadcast  streamy  to  the  space  segment.  Injection  points  are  categorized  as  Primary  Injection  Points 
and  Theater  Injection  Points. 

26.  Metadata  -  A  quick  synopsis  of  a  file.  An  example  might  be  file  name,  classification,  when  the  file 
was  created,  how“  large  the  file  is,  who  created  the  file,  and  a  brief  description  of  the  contents  (i.e., 
image  of  target  x,  map  of  area  y,  and  ATO  for  day  z).  Additional  information  might  also  be  included. 

It  is  usually  attached  as  a  header  to  the  file. 

27.  Manpackable  Receive  Terminal  (MRT)  -  A  manpackable  GBS  receive  terminal  suitable  for  special 
operations. 

28.  Manually  Connected  (MC)  Mode  -  In  this  mode,  the  receive  suite  can  receive  the  GBS  broadcast 
and  the  end  user  has  access  to  some  type  of  manual  communications  system.  A  human-in-the-loop  is 
required  for  submitting  user  pull  requests  or  requesting  the  rebroadcast  of  data  products.  In  other 
words,  the  user  calls  in  a  request  using  whatever  existing  communications  capability  is  available. 

29.  Mobile  -  Capable  of  communicating  while  moving. 

30.  Near-Real-Time  Dissemination  (NRTD):  NRTD  is  a  tool  for  the  dissemination  of  time  critical 
intelligence  information  to  the  Warfighter  and  supporting  elements.  NRTD  takes  inputs  from  SIGINT 
and  other  intelligence  sources,  sanitizes  the  information  to  the  appropriate  user  specific  classification 
level,  and  provides  the  information  via  existing 

3 1 .  Client  Server  (CS)  and  Broadcast  dissemination  means.  NRTD  provides  a  graphically  displayed 
combined,  correlated  and  deconflicted  picture  of  the  battlefield.  NRTD  provides  various  interactive 
channels,  segregated  by  security  level,  for  operational  and  technical  support.  The  Producer  Multi¬ 
level  Interaction  Net  (PMIN)  provides  the  ability  to  interface  and  exchange  information  with  other 
users,  as  well  as  the  NRTD  24-hour  Watch,  across  multiple  security  levels. 

32.  Near  Worldwide  Coverage  -  An  area  65  o  North  latitude  to  65  o  South  latitude,  with  longitude 
coverage  limited  by  the  UHF  Follow-On  satellite  footprint. 

33.  Operational  Control  -  For  the  purpose  of  this  CONORS,  operational  control  focuses  on  the  CINC’s 
ability  to  control  GBS  as  an  information  system.  The  elements  which  this  concept  includes  are  the 
management  functions  (SBM  and  TIM)  and  the  GBS  payload.  The  TIM  functions  are  the  tools 
available  to  the  CINC  to  exercise  this  operational  control  over  information  resources  which  are  only  a 
part  of  the  entire  payload  on  any  one  GBS  satellite.  The  SBM  functions  are  the  execution  elements  of 
the  CINC’s  operational  control. 

34.  Partially  Connected  (PC)  Mode  -  In  this  mode,  the  receive  suite  can  receive  the  GBS  broadcast  and 
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provide  a  means  to  transmit  using  standard  protocols  and  applications,  user  puli  or  rebroadcast 
requests.  The  rebroadcast  requests  are  automatically  generated;  however,  full  virtual  duplex 
connectivity  is  not  achieved  and  user  pull  is  not  automatically  generated.  The  users  must  still  request 
their  products  from  the  source  by  whatever  means  are  available  to  them.  The  likelihood  that  the  users 
are  connected  to  some  existing  network  is  high  and  they  will  make  their  user  pull  requests  via  the 
various  applications  programs  they  have  access  to  (e.g.,  SIPRNET  and  INTELINK) 

35.  Primary  Injection  Point  (PIP)  -  A  fixed  injection  system  that  provides  the  primary  uplink  of  the 
broadcast  streams  from  the  broadcast  management  segment  to  the  space  segment. 

36.  Receive  Broadcast  Management  -  The  set  of  functions,  processes,  and  systems  associated  with 
receiving  and  disseminating  the  file  and  stream  information  contained  within  the  broadcast  to  end 
users.  Receive  broadcast  management  functions  include  interfacing  on  the  physical  layer  between  the 
receive  suite  and  the  end  user  system;  enabling  remote  commanding  and  tuning;  filtering  and  routing 
information;  identifying  missing  or  damaged  files;  enabling  user  profiling;  decoding  and  displaying 
program  guides,  product  catalogs  and  schedules;  and  providing  anti-virus  defense. 

37.  Receive  Only  (RO)  Mode  -  In  this  mode,  the  receive  suite  can  only  receive  the  GBS  broadcast.  There 
is  no  manual  or  automatic  communications  channel  available.  In  this  case,  the  user  has  no  means  to 
request  products  to  initiate  User  Pull. 

38.  Receive  Site  -  A  location  capable  of  receiving  the  GBS  downlink  directly  from  the  satellite.  Receive 
sites  will  be  fixed,  transportable,  and  mobile. 

39.  Receive  Suite  -  The  receive  terminal,  cryptographic  equipment,  and  receive  broadcast  management 
hardware  and  software  required  to  support  an  end  user’s  information  delivery  and  dissemination 
requirements. 

40.  Receive  Terminal  -  The  hardware  and  software  that  implements  the  functions  necessary  to  receive  the 
downlink  broadcast  streams  and  convert  them  to  data  streams  for  subsequent  processing  and 
dissemination  by  the  receive  broadcast  management  hardware  and  software.  Receive  terminals  are 
categorized  as  ground,  airborne,  shipboard  and  submarine. 

41 .  Satellite  Broadcast  Management  -  The  set  of  functions,  processes,  and  systems  associated  with 
collecting  information  products,  assembling  broadcast  streams,  and  transmitting  these  streams  to  the 
injection  point  for  uplink  to  the  space  segment.  Satellite  broadcast  management  functions  include 
building  the  schedule  and  program  guide,  coordinating  information  products,  conducting  traffic 
analysis,  constructing  and  transmitting  the  broadcast  stream,  providing  for  protection  of  the  data, 
technically  controlling  the  GBS  broadcast,  controlling  remote  enabling/disabling,  and  establishing  and 
maintaining  the  user  profile  data  base. 

42.  Scalable  Architecture  -  The  capability  of  the  GBS  system  architecture  to  support  an  array  of 
capabilities  and  terminal  configurations  required  to  meet  the  end  users’  operational  needs.  For 
example,  the  transmit  and  receive  data  rates  will  vary  dynamically  with  the  capabilities  of  the  injection 
and  receive  terminals.  The  capability  of  the  receive  suite  will  vary  depending  on  whether  the 
equipment  will  be  used  in  a  stand-alone  or  networked  configurations. 

43.  Shipboard  Receive  Terminal  (SRT)  -  A  GBS  receive  terminal  that  is  installed  on  ship-board 
platforms.  This  receiver  will  receive  while  on  the  move. 

44.  Smart  Push  -  The  capability  for  the  end  user  to  define  information  requirements  in  advance  so  that  the 
GBS  system  can  tailor  broadcast  services  without  regard  to  specific  user  requests. 

45.  Space  Segment  -  The  space-borne  elements  of  the  GBS  system,  consisting  of  the  broadcast  satellite 
packages  and  satellite  command  and  control  systems. 

46.  Stream  -  A  continuous  or  variable  duration  information  product  that  originates  from  a  national  or 
theater  source.  Real  time  video  is  an  example  of  a  stream  product. 

47.  Sub-surface  Receive  Terminal  (SSRT)  -  A  GBS  receive  terminal  that  is  installed  on  submarine 
platforms.  This  receiver  will  receive  while  on  the  move  at  periscope  depth. 

48.  Tactical  Data  Information  Exchange  Subsystem  (TADIXS)-B:  The  TADIXS-B  broadcast 
distributes  National  generated  data  to  operational  forces  and  commanders  worldwide.  The  information 
delivered  directly  to  tactical  users  can  be  used  to  support  I  &  W,  surveillance  data,  targeting  (to 
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include  Over  the  Horizon  Targeting  (OTH-T)),  maneuver,  execution,  and  battle  damage  assessment. 

49.  Tactical  Information  Broadcast  Service  (TIBS):  IBS  provides  near  real  time  situation  awareness 
information  from  an  open  network  of  interactive  participants  using  multiple  sensors  and  sources.  The 
TIBS  broadcast  uses  UHF  SATCOM  assets  for  network  operation  and  for  the  relay  of  out-of-theater 
specific  information  into  the  tactical  users  area  of  operations.  TIBS  participants  include  a  wide 
variety  of  national,  airborne,  surface,  and  subsurface  platforms.  (TIBS  ORD,  approved  9  Dec  96.) 

50.  Tactical  Related  Applications  (TRAP)  Data  Dissemination  System  (TDDS):  The  TDDS  broadcast 
provides  global  surveillance  information  in  time  for  sensor  cueing,  and  I  &  W.  Data  is  forwarded 
from  sensor  to  communications  gateway/relay  for  dissemination  to  worldwide  military  users  via 
geosynchronous  UHF  satellite  links.  TDDS  data  sources  include  national  and  tactical  sensor  systems. 
(TRAP  ORD,  approved  6  Jun  93;  Draft  TDDS  ORD,  draft  as  of  Feb  96) 

51.  Tactical  Reconnaissance  Intelligence  Exchange  System  (TRIXS):  TRIXS  provides  high  accuracy 
targeting  data  to  multi-service/Joint  Services  Command  Control  and  Intelligence  (C2I)  users.  The 
TRIXS  network  supports  full-duplex  data  and  half-duplex  voice  connectivity  between  user  terminals 
and  is  designed  to  provide  in  time  intelligence  reports  focused  on  high  pay  off  ground  threat  to  joint 
forces  battle  managers  at  all  echelons  to  support  maneuver,  threat  avoidance,  targeting,  mission 
planning,  and  sensor  cueing.  The  TRIXS  network  can  support  up  to  five  intelligence  producers 
including  the  Army  Guardrail  Common  Sensor  (GRCS),  Air  Force  Contingency  Airborne 
Reconnaissance  System  (CARS),  the  Navy  Story  Teller  System,  and  the  Airborne  Reconnaissance 
Low  (ARL).  (TRIXS  is  capable  of  operating  at  both  the  Secret  and  TS/SCI  levels.  The  TRIXS  LOS 
SCI  capability  will  be  retained  until  the  IBS  has  fully  incorporated  multi-level  security.)  (GRCS 
ROC,  approved  24  Apr  92.) 

52.  Theater  Injection  Point  (TIP)  -  A  transportable  injection  system  that  provides  the  capability  for 
theater  commanders  to  transmit  information  directly  from  within  a  theater  to  the  space  segment.  A  TIP 
incorporates  the  necessary  TIM  and  SBM  functions  needed  to  carry  out  its  mission, 

53.  Theater  Information  Management  (TIM)  -  The  set  of  functions,  processes,  and  systems  associated 
with  control  and  management  of  GBS  that  provides  individual  CINCs  with  the  control  essential  for 
delivery  of  the  correct  information  products  to  their  forces  worldwide.  TIM  functions  include  directing 
GBS  operations,  coordinating  the  broadcast  schedule,  managing  apportioned  resources,  identifying 
new  products,  reviewing  and  validating  the  user  profile  data  base,  and  auditing  User  Pull. 

54.  Transportable  -  Capable  of  being  moved  from  one  location  to  another  and  communicating  from  a 
fixed  location  (not  while  on  the  move)'. 

55.  Transportable  Ground  Receive  Terminal  (TGRT)  -  A  GBS  receive  terminal  packaged  to  provide 
portable  capability.  This  receiver  will  not  receive  while  on  the  move. 

56.  User  Profile  -  A  record  of  information  which  identifies  a  specific  user,  his  information  needs,  address, 
accesses,  and  other  selected  data  that  can  be  helpful  to  the  user  and  to  information  managers  in 
ensuring  the  user  receives  complete  support  from  GBS, 

57.  User  Pull  -  The  capability  for  end  users  to  define  specific  information  to  be  broadcast  on  demand  in 
response  to  operational  circumstances,  or  the  actual  end  user  request  for  specific  information  to  be 
broadcast  on  demand.  “User  Pull”  requests  are  made  via  a  backchannel. 

58.  Virtual  Injection  -  The  process  of  utilizing  organic  communications  paths  (non-satellite)  to  transmit 
in-theater  generated  information  to  a  Primary  Injection  Point  for  broadcast  to  users  in  theater. 

59.  Wrapper  -  An  electronic  header  added  to  file  products  containing  metadata  which  allows  the  SBM  to 
schedule  dissemination.  Receive  suites  can  use  the  wrapper  to  ascertain  addressing  and  then  filter  and 
process  products. 

60.  Worldwide  Coverage  -  An  area  65  o  North  latitude  to  65  o  South  latitude,  180  o  West  to  180o  East 
longitude. 
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APPENDIX  M.  ACRONYMS  [GBS,  IBS] 


1 .  A&T  -  Acquisition  and  Technology 

2.  ACAT  -  Acquisition  Category 

3.  ACTD  -  Advanced  Concept  Technology  Demonstration 

4.  AE  -  Acquisition  Executive 

5.  AF  -  Air  Force 

6.  AFFOR  -  Air  Force  Forces 

7.  AFOTEC  -  Air  Force  Operational  Test  and  Evaluation  Center 

8.  AFRTS  -  Armed  Forces  Radio  and  Television  System 

9.  AIS  -  Automated  Information  System 

10.  AO  -  Area  of  Operations 

1 1 .  AOR  -  Area  of  Responsibility 

12.  ARFOR  Readiness  Group 

13.  ARL  -  Air-  Army  Forces 

14.  ARG  -  Amphibious  borne  Reconnaissance  Low 

15.  ART  -  Airborne  Receive  Terminal 

16.  ASD  -  Assistant  Secretary  of  Defense 

17.  ATM  -  Asynchronous  Transfer  Mode 

18.  ATO  -  Air  Tasking  Order 

19.  BADD  -  Battlefield  Awareness  and  Data  Dissemination 

20.  BC2A  -  Bosnia  Command  and  Control  Augmentation 

21 .  BDA  -  Bomb  Damage  Assessment 

22.  BER  -  Bit  Error  Rate 

23.  BIT  -  Build-in  Test 

24.  BM  -  Broadcast  Management 

25.  C2  -  Command  and  Control 

26.  C2I  -  Command,  Control  and  Intelligence 

27.  C3I  -  Command,  Control,  Communication  and  Intelligence 

28.  C4I  -  Command,  Control,  Communication,  Computers  and  Intelligence 

29.  CARS  -  Contingency  Airborne  Reconnaissance  System 

30.  CASS  -  Consolidated  Automated  Support  System 

3 1 .  CIBS-M  -  Common  Integrated  Broadcast  System  Module 

32.  CfNC  -  Commander-in-Chief 

33.  CJCS  -  Chairman,  Joint  Chiefs  of  Staff 

34.  CJCSM- Chairman  Joint  Chiefs  of  Staff  Memo 

35.  CJTF  -  Commander  Joint  Task  Force 

36.  CMSA  -  Cruise  Missile  Support  Activity 

37.  CNN  -  Cable  News  Network 

38.  CNO  -  Chief  of  Naval  Operations 

39.  COE  -  Common  Operating  Environment 

40.  COMSEC  -  Communications  Security 

4 1 .  CONOPS  -  Concept  of  Operations 

42.  CONUS  -  Continental  United  States 

43.  COP  -  Common  Operating  Picture 

44.  COTS  -  Commercial  Off-the-Shelf 

45.  CS  -  Client  Server 

46.  CTAPS  -  Contingency  Theater  Automated  Planning  System 

47.  CTT  -  Commanders  Tactical  Terminal 
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48.  DAM  A  -  Demand  Assign  Multiple  Access 

49.  DARPA  “  Defense  Advanced  Research  Projects  Agency 

50.  DBS  -  Direct  Broadcast  Service 

5 1 .  DED  -  Data  Element  Dictionary 

52.  DGIAP  -  Defense  General  Intelligence  Applications  Program 

53.  DIA  -  Defense  Intelligence  Agency 

54.  DII  -  Defense  Information  Infrastructure 

55.  DISA  -  Defense  Information  System  Agency 

56.  DISN  -  Defense  Information  System  Network 

57.  DMS  -  Defense  Message  System 

58.  DOD  -  Department  of  Defense 

59.  DSCS  -  Defense  Satellite  Communications  System 

60.  DTD  -  Dated 

61.  EHF  -  Extremely-High  Frequency 

62.  EKMS  -  Electronic  Key  Management  System 

63.  EMP  -  Electromagnetic  Pulse 

64.  EOB  -  Electronic  Order  of  Battle/Enemy  Order  of  Battle 

65.  ERDB  -  Emerging  Requirements  Database 

66.  ETIE  -  Expanded  Tactical  Information  Element 

67.  EW  -  Electronic  Warfare 

68.  FC  -  Fully  Connected 

69.  FGRT  -  Fixed  Ground  Receive  Terminal 

70.  FOC  -  Full  Operational  Capability 

71.  FOV- Field  of  View 

72.  FSSG  -  Force  Service  Support  Group 

73.  FY- Fiscal  Year 

74.  GBS  -  Global  Broadcast  Service 

75.  GCCS  -  Global  Command  and  Control  System 

76.  GCSS  -  Global  Combat  Support  System 

77.  GMF  -  Ground  Mobile  Forces 

78.  GMRT  -  Ground  Mobile  Receive  Terminal 

79.  GOSC  -  General  Officer  Steering  Committee 

80.  GOTS  -  Government  Off-the-Shelf 

81.  GPS  -  NAVSTAR  Global  Positioning  System 

82.  GRAT  -  GBS  Resource  Allocation  Tool 

83.  GRCS  -  Guardrail  Common  Sensor 

84.  GRT  -  Ground  Receive  Terminal 

85.  HDR  -  High  Data  Rate 

86.  HEMP  -  High-altitude  electromagnetic  pulse 

87.  HQ  -  Headquarters 

88.  HSFB  -  High  Speed  Fleet  Broadcast 

89.  HUMINT  -  Human  Intelligence 

90.  I  &  W  -  Indications  and  Warning 

91.  IBS  -  Integrated  Broadcast  Service 

92.  ICDB  -  Integrated  Communications  Database 

93.  IDM  -  Information  Dissemination  Management 

94.  IME  -  Information  Management  Element 

95.  IMINT  -  Imagery  Intelligence 

96.  INFOSEC  -  Information  Security 

97.  IOC  -  Initial  Operational  Capability 

98.  IP  -  Internet  Protocol 
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99.  IRD  -  Integrated  Receiver/Decoder 
lOO.IRINT  -  Infrared  Intelligence 

10  MRS  -  Interface  Requirements  Specification 
102.IW  -  Information  Warfare 

103.  JAC  -  Joint  Analysis  Center 

104. JBS  -  Joint  Broadcast  Service 

105. JCIT  -  Joint  Combat  Information  Terminal 

106.  JCS  -  Joint  Chiefs  of  Staff 

107. JDISS  -  Joint  Deployable  Intelligence  Support  System 

108. JIBSG  -  Joint  Integrated  Broadcast  Steering  Group 

109. JIC  -  Joint  Intelligence  Center 

1  lO.JITI  -  Joint  In-Theater  Injection 

1 1  l.JMCIS  -  Joint  Maritime  Command  Information  System 

1 12. JMIP  -  Joint  Military  Intelligence  Program 

1 13. JORD  -  Joint  Operational  Requirements  Document 

1 14. JPD  -  Joint  Potential  Designator 

1 1 5.  JPO  -  Joint  Program  Office 

116. JS- Joint  Staff 

1 17. JSOTF  -  Joint  Special  Operations  Task  Force 

1 18. JTA  -  Joint  Technical  Architecture 

1 19. JTF  -  Joint  Task  Force 

120. JTIDS  -  Joint  Tactical  Information  Distribution  System 

121. JTT  -  Joint  Tactical  Terminal 

122. JV2010  -  Joint  Vision  2010 

123. JWCA  -  Joint  Warfighter  Capability  Assessment 

124. JWICS  -  Joint  Worldwide  Intelligence  Communications  System 

125. JWID  -  Joint  Warrior  Interoperability  Demonstration 

126. KPP  -  Key  Performance  Parameters 

127. LDR  -  Low  Data  Rate 

128. LORA  -  Level  of  Repair  Analysis 

129. LOS  -  Line  of  Sight 

130. LRU  -  Line  Replaceable  Unit 
13 1  .MAG  -  Marine  Air  Group 

132. MARFOR  -  Marine  Forces 

133. MASINT  -  Measurement  and  Signature  Architecture  Intelligence 

134. MATT  -  Multi-Mission  Advanced  Tactical  Terminals 

135. MAW  -  Marine  Air  Wing 

136. Mbps  -  Megabits  per  second 

137. MC  -  Manually  Connected 

138. MCC  -  Mobile  Command  Center 

139. MCEB  -  Military  Communications  Electronic  Board 

140. MDU  -  Mission  Data  Update 

141. MEF  -  Marine  Expeditionary  Force 

142. MEU  -  Marine  Expeditionary  Unit 

143. METOC  -  Meteorological  and  Oceanographic 

144. MILSATCOM  -  Military  Satellite  Communications 

145. MJPO  -  MILSATCOM  Joint  Program  Office 

146. MLDT  -  Mean  Logistic  Delay  Time 

147. MNS  -  Mission  Need  Statement 

148. MOA  -  Memorandum  of  Agreement 

149. MOP  -  Memorandum  of  Policy 
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150.MPT  -  Manpower,  Personnel  and  Training 
15  LMRCs  -  Major  Regional  Conflicts 

152.  MRT  -  Manpackable  Receive  Terminal 

153. MTBOMF  -  Mean  Time  Between  Operational  Mission  Failure 

154. MTN  -  M22  Tactical  Network 

155. MTT  -  Mobile  Training  Teams 

156. MTTR  -  Mean  Time  To  Repair 

157. NAIC  -  National  Air  Intelligence  Center 

158. NATO  -  North  Atlantic  Treaty  Organization 

1 59. NAVFOR  -  Naval  Forces 

160. NAVSATCOMFAC  -  Naval  Satellite  Communications  Facility 

161.  NBC  -  Nuclear  Biological  Chemical 

162. NBCC  -  Nuclear,  Biological,  and  Chemical  Contamination 

163. NCTAMS  -  Naval  Computer  and  Telecommunications  Area  Master  Station 

164. NIMA  -  National  Imagery  and  Mapping  Agency 

165. NIPRNET  -  Non-secure  Internet  Protocol  Router  Network 

166. NITF  -  National  Imagery  Transmission  Format 

167. nm  -  nautical  mile 

168. NMC  -  Network  Management  Center 

169. NMS  -  National  Militaiy  Strategy 

170. NRO  -  National  Reconnaissance  Office 
171  .NRTD  “  Near-Real-Time  Dissemination 
172.NSA  -  National  Security  Agency 
173.0  «  Objective 

174.0&M  -  Operational  and  Maintenance 
175. ONI  -  Office  of  Naval  Intelligence 
176.00B  -  Order  of  Battle 
177.0RD  -  Operational  Requirements  Document 
178. OTAR  -  Over  the  Air  Re-keying 
179.0TH-H  -  Over  the  Horizon  Targeting 

1 80. PBD  -  Program  Budget  Decision 

181.  PC  -  Personal  Computer/Partially  Connected 

182.  PIP  -  Primary  Injection  Point 

183. PMIN  -  Producer  Multi-level  Interaction  Net 

184. RADINT  -  RADAR  Intelligence 

185. RBM  -  Receive  Broadcast  Management  (Manager) 

186. RBS  -  Readiness  Based  Sparing 

187. RF  -  Radio  Frequency 

188. RFI  -  Request  for  Information 

189. ro  -  Receive  Only 

190. RT  -  Receive  Terminal 

191.SAS0  -  Stability  and  Support  Operations 
192.SATCOM  -  Satellite  Communications 
1 93 .  SATCOM  -  Satellite  Communications 
194.SBM  -  Satellite  Broadcast  Management  (Manager) 

195. SCI  -  Sensitive  Compartmented  Information 

196.  SHF  -  Super-High  Frequency 

197.SIGINT  -  Signal  Intelligence 

198.SIPRNET  -  Secure  Internet  Protocol  Router  Network 

199.SMO  -  Support  to  Military  Operations 

200.  SOA  -  System  Operational  Availability 
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201.SOF  -  Special  Operations  Forces 

202.SOM  -  System  Operational  Manager 

203. SPA  WAR  -  Space  and  Naval  Warfare  Systems  Command 

204.SRT  -  Shipboard  Receive  Terminal 

205. SRU  -  Smallest  Replaceable  Unit 

206.SSRT  -  Sub-surface  Receive  Terminal 

207.STAR  -  System  Threat  Assessment  Report 

208. T  -  Threshold 

209. TACS  -  Theater  Air  Control  System 

210. TADIL-J  -  Tactical  Digital  Information  Link  J  (NATO  designation  is  Link  16) 
21  l.TADIXS  B  -  Tactical  Data  Information  Exchange  Subsystem  B 

212. TAFIM  -  Technical  Architecture  for  Information  Management 

213. TBD  -  To  be  determined 

214. TBR  -  To  be  reviewed 

215. TCN  -  Terrestrial  communications  network 

216. TCP  -  Transmission  Control  Protocol 

217. TDDS  -  TRAP  Data  Dissemination  System 

218. TDL  -  Tactical  Data  Link 

219. TDP  -  Tactical  Data  Processor 

220. TED  -  Threat  Environment  Description 
221  .TEMP  -  Test  and  Evaluation  Master  Plan 

222. TGRT  -  Transportable  Ground  Receive  Terminal 

223.  TIARA  -  Tactical  Intelligence  and  Related  Activities 

224. TIBS  -  Tactical  Information  Broadcast  Service 

225. TIE  -  Tactical  Information  Element 

226.  TIM  -  Theater  Information  Management  (Manager) 

227. TIP  -  Theater  Injection  Point 

228. TOC  -  Tactical  Operations  Center 

229. TOD  -  Time  of  Day 

230. TOE-TOR  -  Time  of  Entry  into  IBS  to  Time  of  Receipt  by  user 

231. TRANSEC  -  Transmission  Security 

232. TRAP  -  Tactical  Related  Applications 

233. TRIXS  -  Tactical  Reconnaissance  Intelligence  Exchange  System 

234. TS  -  Top  Secret 

235. TSBM  -  Transportable  Satellite  Broadcast  Manager 

236. TT&C  -  Telemetry,  Tracking,  and  Commanding 

237. UAV  -  Unmanned  Aerial  Vehicle 

238. UFO  -  UHF  Follow-On 

239. UHF  -  Ultra-High  Frequency 

240. USACOM  -  United  States  Atlantic  Command 

241.  USD  -  Under  Secretary  of  Defense 

242. USEUCOM  -  United  States  European  Command 

243. USSOCOM  -  United  States  Special  Operations  Command 

244. USSOUTHCOM  -  United  States  Southern  Command 

245. USSPACECOM  -  United  States  Space  Command 

246. UTM  -  Universal  Transverse  Mercator 

247.  VHF  -  Very  High  Frequency 

248. VSAT  -  Very  Small  Aperture  Terminal 

249.  VTC  -  Video-Teleconferencing 

250.  WGS  -  World  Geodetic  System 
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